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Technical  Progress 

In  Che  original  proposal  we  had  outlined  a  long  term  program  £or  conducting 
research  in  knowledge  based  systems.  In  particular  we  proposed  to  study 
issues  in  diagnostic  reasoning  and  in  knowledge-directed  information 
retrieval.  During  the  first  year  most  of  the  progress  came  in  the  area  of 
diagnostic  reasoning  and  in  the  conceptual  foundations  of  knowledge-based 
systems  in  general.  We  also  developed  an  approach  to  a  new  type  of  task: 
design  of  mechanical  parts. 


In  particular,  the  following  specific  progress  was  made.  (We  will  summarize 
the  nature  of  the  result  here  and  attach  a  paper  in  each  case  that  gives 
details  of  the  results.) 

1.  We  have  elaborated  our  theory  of  types  of  problem  solving  that 
underlies  expert  reasoning.  The  idea  is  that  a  complex  task  can 
often  be  broken  down  into  a  number  of  generic  tasks .  for  each  of 
which  a  particular  problem  solving  regime  is  appropriate.  Each  of 
these  tasks  can  be  solved  by  a  collection  of  conceptual  specialists 
among  whom  knowledge  of  the  domain  is  distributed.  These 
specialists  solve  the  problem  by  engaging  in  that  generic  type  of 
problem  solving  by  exchanging  messages  of  specific  types.  We  have 
enclosed  as  appendix  a  paper,  "Towards  a  Taxonomy  of  Problem 
Solving  Types,"  which  appeared  in  the  AI  Magazine,  which  gives  the 
details  of  the  theory. 

2.  In  earlier  work  we  had  developed  approaches  to  three  generic  types 
of  problem  solving:  diagnosis,  knowledge-directed  data  retrieval, 
What-Will-Happen-If  type  of  reasoning.  During  the  period  of 
research  under  report,  we  formulated  another  important  type  of 
problem  solving:  design  by  refining  plans.  We  have  been  applying 
the  approach  to  the  implementation  of  an  expert  system  for 
mechanical  design.  The  attached  paper,  "An  Approach  to  Expert 
Systems  for  Mechanical  Design,"  was  presented  at  the  IEEE  Computer 
Society,  Trends  &  Applications  Conference. 

3.  We  have  developed  (with  support  from  another  source)  a  tool  for 
efficient  construction  of  diagnostic  expert  systems.  This  tool  is 
a  high  level  language  called  CSRL.  Under  this  grant  support  we 
have  been  experimenting  with  the  application  of  this  tool  to  the 
design  and  implementation  of  expert  systems  in  the  area  of 
mechanical  systems,  since  that  was  one  of  the  domains  that  we 
emphasized  in  the  original  proposal.  We  reported  on  this  language 


at  the  last  International  Joint  Conference  on  Artificial 
Intelligence  at  Karlsruhe.  The  paper  from  that  Proceedings 
reporting  on  CSRL  is  enclosed.  We  also  include  with  this  report 
another  technical  report  that  discusses  our  experience  in  using 
this  tool  in  the  construction  of  an  expert  system  for  fuel  systems 
for  automobiles. 

4.  We  have  been  investigating  the  issues  related  to  how  an  expert 
system  may  have  "deep"  knowledge  of  its  domain  and  use  it  to  do 
problem  solving,  as  opposed  to  the  current  generation  of  expert 
systems  that  use  what  one  might  call  "compiled"  knowledge.  E.g. 
all  the  current  expert  systems  in  medicine  have  knowledge  relating 
symptoms /manifestations  and  diseases  explicitly  encoded  in  the 
knowledge  base.  However,  often  a  person  who  has  an  understanding 
of  the  domain  will  be  able  to  derive  these  relationships  from  a 
deeper  model.  We  have  developed  a  language  in  which  the 
understanding  of  an  agent  about  how  a  device  works  may  be  encoded. 
This  language  expresses  how  a  function  of  a  device  may  be  related 
to  the  behavior  and  structure  of  it  and  its  components.  In 
addition  we  have  developed  a  compiler  which  can  work  on  this 
functional  representation  and  produce  a  diagnostic  expert  system. 
This  result  is  of  considerable  significance  we  think,  since  it  will 
enable  for  the  first  time  a  representation  of  "understanding"  of  a 
device.  We  have  applied  this  methodology  to  the  representation  of 
the  functions  of  a  household  electric  buzzer  and  show  how  the 
compiler  generates  a  dignostic  problem  solver  from  this.  A  paper 
reporting  on  this  is  attached  as  appendix  to  the  report. 

5.  We  have  been  looking  into  how  capabilities  of  various  expert  system 

approaches  can  be  characterized.  A  methodology  by  which  a  complex 
real  world  decision  task  may  be  decomposed  into  generic  tasks  and 
techniques  suited  for  various  generic  tasks  can  then  be  applied  is 
outlined  in  another  attached  paper,  "Expert  Systems:  Matching 

Techniques  to  Tasks,"  which  was  presented  as  an  invited  talk  at  the 
Hew  York  University  Symposium  on  Expert  Systems  for  Business 
Applications.  This  will  shortly  appear  as  an  article  in  a  book  of 
that  title. 

Personnel  Activities 


Two  items  of  interest  need  to  be  mentioned  here.  Prof.  B.  Chandrasekaran,  the 
PI  for  the  Grant,  spent  3  months  at  the  MIT  Laboratory  for  Computer  Science  as 
a  Visiting  Scientist  during  the  research  period.  He  worked  with  Prof.  Peter 
Szolovits  and  Prof.  Ramesh  Patil  on  several  aspects  of  expert  systems.  He 
also  spent  one  month  at  Carnegie  Mellon  University  under  the  sponsorship  of 
Prof.  A.  Newell.  A  portion  of  his  support  for  these  visits  came  from  the 
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AFOSR  Grant.  Zn  addition  to  these  major  visits,  Prof.  Chandrasekaran  gave  a 
number  of  talks  at  BBN,  GTE  Labs,  NRL  AI  Lab.,  and  other  places  over  the  year. 

Mr.  Tom  Bylander,  a  Graduate  Research  Associate  under  the  Grant,  von  an  award 
for  travel  to  the  International  Joint  Conference  on  Artificial  Intelligence  to 
present  the  paper  on  CSRL. 

Computing  Environment 

Quite  a  bit  of  our  effort  vent  into  gearing  up  for  the  introduction  of  Lisp 
machines  into  our  computing  environment.  These  machines  will  be  arriving 
shortly.  A  number  of  changes  will  need  to  be  made  in  the  language 
environment:  we  are  moving  into  an  Interlisp  environment,  and  many  of  our 
tools  are  being  recoded  for  that  environment. 


LIST  OF  PAPERS  IN  APPENDIX 


1.  "Towards  a  Taxonomy  of  Problem  Solving  Types"  by  B.  Chandrasekaran 

2.  "An  Approach  to  Expert  Systems  for  Mechanical  Design"  by  David 
C.  Brown  and  B.  Chandrasekaran 

3.  "CSRL:  A  Language  for  Expert  Systems  for  Diagnosis"  by  Tom 
Bylander,  Sanjay  Mittal,  and  B.  Chandrasekaran 

4.  "Application  of  the  CSRL  Language  to  the  Design  of  Expert  Diagnosis 

Systems:  The  Auto-Mech  Experience"  by  Michael  C.  Tanner  and  Tom 

By lander 

5.  "A  Representation  for  the  Functioning  of  Devices  that  Supports 
Compilation  of  Expert  Problem  Solving  Structures"  by  V.S.  Moorthy 
and  B.  Chandrasekaran 

6.  "Expert  Systems:  Matching  Techniques  to  Tasks"  by 

B.  Chandrasekaran 


Towards  a  Taxonomy 
Of  Problem  Solving  Types 


B.  Chandrasekaran 


Department  of  Computer  and  Information  Science 
The  Ohio  State  University 
Columbus,  Ohio  4$2lO  USA 


Abstract 

Our  group’s  work  in  medical  decision  making  has  led  us  to  formulate 
a  framework  for  expert  system  design,  in  particular  about  how  the 
domain  knowledge  may  be  decomposed  into  substructures.  We  propose 
that  there  exist  different  problem-solving  types,  i.e.,  uses  of  knowledge, 
end  corresponding  to  each  is  a  separate  substructure  specialising  in 
that  type  of  problem-solving-  Each  substructure  is  in  turn  further 
decomposed  into  a  hierarchy  of  specialists  which  differ  from  each  other 
not  in  the  type  of  problem-solving,  but  in  the  conceptual  content  of 
their  knowledge;  e.g.,  one  of  them  may  specialise  in  “heart  disease.' 
while  another  may  do  so  in  “liver,'  though  both  of  them  are  doing  the 
same  type  of  problem-solving.  Thus  ultimately  all  the  knowledge  in  the 
system  is  distributed  among  problem-sol  vers  which  know  how  to  use 
that  knowledge.  This  is  in  contrast  to  the  currently  dominant  expert 
system  paradigm  which  proposes  a  common  knowledge  base  accessed 
by  knowledge-free  problem-solvers  of  various  kinds.  In  our  framework 
there  is  no  distinction  between  knowledge  beses  and  problem-solvers: 
each  knowledge  source  it  a  problem-solver.  We  have  so  far  had  occa¬ 
sion  to  deal  with  three  generic  problem-solving  types  in  expert  clinical 
reasoning:  diagnosis  (classification),  data  retrieval  and  organisation, 
and  reasoning  about  consequences  of  actions.  In  a  novice,  these  expert 
structures  are  often  incomplete,  and  other  knowledge  structures  and 
learning  processes  are  needed  to  construct  and  complete  them. 


This  is  a  revised  and  extended  version  of  an  invited  talk  entitled. 
“Decomposition  of  Domain  Knowledge  Into  Knowledge  Sources:  The 
MDX  Approach.'  delivered  at  the  IV  National  Conference  of  the 
Canadian  Society  for  Computational  Studies  of  Intelligence.  May  IT- 19. 
I  M2.  Saskatchewan. 


Introduction 

For  the  past  few  years  our  research  group  has  been  in¬ 
vestigating  the  issues  of  problem-solving  as  well  as  knowledge 
organization  and  representation  in  medical  decision  making. 
In  parallel  with  this  investigation  we  have  also  been  build¬ 
ing  and  extending  a  cluster  of  systems  for  various  aspects 
of  medical  reasoning.  The  major  system  in  this  cluster  is 
MDX.  which  is  a  diagnostic  system,  i.e.,  its  role  is  to  ar¬ 
rive  at  a  classification  of  a  given  case  into  a  node  of  a  diag¬ 
nostic  hierarchy.  The  theoretical  basis  of  this  diagnostic 
problem-solving  is  laid  out  in  some  detail  in  Gomez  and 
Chandrasekaran. 

The  MDX  system,  which  is  wholly  diagnostic  in  its 
knowledge,  communicates  with  two  auxiliary  systems. 
PATREC  and  RAD  EX.  PATREC  is  a  data  base  assistant 
in  the  sense  it  acquires  the  patient  data,  organizes  them, 
and  answers  the  queries  of  MDX  concerning  the  patient 
data.  In  all  these  activities  PATREC  uses  various  types  of 
inferential  knowledge  embedded  in  an  underlying  concep¬ 
tual  model  of  the  domain  of  medical  data.  RADEX  is  a 
radiology  consultant  to  MDX.  and  it  suggests  or  confirms 
diagnostic  possibilities  by  reasoning  baaed  on  its  knowledge 
of  imaging  procedures  and  relevant  anatomy.  See  Mittal 
and  Chandrasekaran  (Mittal.  Chandrasekaran.  1981)  and 
Chandrasekaran  et  al  (Chandrasekaran.  Mittal  and  Smith. 
1980)  for  further  details  about  these  subsystems. 
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Though  in  a  sense  RAD  EX  and  PATREC  can  both  be 
viewed  as  ‘intelligent”  data  base  specialists,  RAD  EX  has 
some  additional  features  of  interest  due  to  the  perceptual 
nature  of  some  of  its  knowledge.  However,  for  the  purpose 
of  this  paper,  it  is  not  necessary  to  go  into  RAD  EX  in  much 
detail,  and  we  can  view  PATREC  as  prototypical  of  this  class 
of  auxiliary  systems. 

Our  aim  in  this  paper  is  to  outline  a  point  of  view  about 
how  a  domain  gets  naturally  decomposed  into  substructures 
each  of  which  specializes  in  one  type  of  problem-solving. 
Each  of  these  substructures  in  turn  further  gets  decomposed 
into  small  knowledge  sources  of  the  same  problem-solving 
type,  but  specializing  in  different  concepts  in  the  domain. 
We  shall  see  that  this  sort  of  decomposition  results  in  more 
natural  control  and  focus  properties  of  the  overall  system. 
Identification  of  these  substructures  and  how  they  communi¬ 
cate  with  one  another  is  vital  to  the  proper  organization  of 
the  body  of  knowledge  for  problem-solving  in  that  domain. 

Our  method  in  this  paper  will  be  to  examine  how 
knowledge  is  used  in  a  few  well-defined  tasks:  diagnosis,  data 
storage  and  retrieval,  and  reasoning  about  consequences  of 
actions.  It  should  be  emphasized  that  these  tasks  are  not  par¬ 
ticular  to  the  medical  domain.  Rather  they  are  fundamental 
generic  tasks  occurring  in  a  wide  variety  of  problem-solving 
situations.  Thus  these  tasks  are  elements  of  a  taxonomy  of 
basic  problem-solving  types.  When  we  are  done  with  this 
examination,  the  general  principles  of  knowledge  decomposi¬ 
tion  will  begin  to  take  on  some  clarity. 

One  final  point:  we  will  use  examples  from  both  medical 
and  non-medical  domains.  In  particular,  there  are  many 
similarities  between  reasoning  about  diseases  and  therapies 
on  one  hand  and  trouble-shooting  and  synthesis  of  corrective 
actions  in  complex  engineering  systems  on  the  other. 

The  Diagnostic  Task 

By  the  term  “diagnostic  task,"  we  mean  something  very 
specific:  the  identification  of  a  case  description  with  a  specific 
node  in  a  pre-determined  diagnostic  hierarchy.  For  the  pur¬ 
pose  of  current  discussion  let  us  assume  that  all  the  data 
that  can  be  obtained  are  already  there,  i.e.,  the  additional 
problem  of  launching  exploratory  procedures  such  as  order¬ 
ing  new  tests  etc.  does  not  exist.  The  following  brief  account 
is  a  summary  of  the  more  detailed  account  given  in  (Gomez, 
Chandrasekaran,  1981)  of  diagnostic  problem-solving. 

Let  us  imagine  that  corresponding  to  each  node  of 
the  classification  hierarchy  alluded  to  earlier  we  identify 
a  “concept.”  The  total  diagnostic  knowledge  is  then  dis¬ 
tributed  through  the  conceptual  nodes  of  the  hierarchy  in  a 
specific  manner  to  be  discussed  shortly.  The  problem-solving 
for  this  task  will  be  performed  top  down,  i.e.,  the  top-most 
concept  will  first  get  control  of  the  case,  then  control  will 
pass  to  an  appropriate  successor  concept,  and  so  on.  In  the 
medical  example,  a  fragment  of  such  a  hierarchy  might  be 
as  shown  in  Fig.  1. 


Hepatitis  Jaundice 

Figure  1. 

More  general  classificatory  concepts  are  higher  in  the 
structure,  while  more  particular  ones  are  lower  in  the  hierar¬ 
chy.  It  is  as  if  INTERNIST  first  establishes  that  there  is  in 
fact  a  disease,  then  LIVER  establishes  that  the  case  at  hand 
is  a  liver  disease,  while  say  HEART  etc.  reject  the  case  as 
being  not  in  their  domain.  After  this  level,  JAUNDICE  may 
establish  itself  and  so  on. 

Each  of  the  concepts  in  the  classification  hierarchy  has 
“how-to”  knowledge  in  it  in  the  form  of  a  collection  of  diag- 
noatie  rules.  These  rules  are  of  the  form:  <  symptoms  >  — 
<  concept  in  hierarchy  >,  e.g.,  “If  high  SGOT.  add  n  units 
of  evidence  in  favor  of  cholestasis.”  Because  of  the  fact  that 
when  a  concept  rules  itself  out  from  relevance  to  a  case,  all  its 
successors  also  get  ruled  out,  large  portions  of  the  diagnostic 
knowledge  structure  never  get  exercised.  On  the  other  hand, 
when  a  concept  is  properly  invoked,  a  small,  highly  relevant 
set  of  rules  comes  into  play. 

The  problem-solving  that  goes  on  in  such  a  structure  is 
distributed.  The  problem-solving  regime  that  is  implicit  in 
the  structure  can  be  characterized  as  an  “ establiah-refine ” 
type.  That  is,  each  concept  first  tries  to  establish  or  reject 
itself.  If  it  succeeds  in  establishing  itself,  the  refinement 
process  consists  of  seeing  which  of  its  successors  can  es¬ 
tablish  itself.  Each  concept  has  several  clusters  of  rules: 
confirmatory  rules,  exclusionary  rules,  and  perhaps  some 
recommendation  rules.  The  evidence  for  confirmation  and 
exclusion  can  be  suitably  weighted  and  combined  to  arrive 
at  a  conclusion  to  establish,  reject  or  suspend  it.  The  last 
mentioned  situation  may  arise  if  there  is  not  sufficient  data 
to  make  a  decision.  Recommendation  rules  are  further  op¬ 
timization  devices  to  reduce  the  work  of  the  subconcepts. 
Further  discussion  of  this  type  of  rules  is  not  necessary  for 
our  current  purpose. 

The  concepts  in  the  hierarchy  are  clearly  not  a  static 
collection  of  knowledge.  They  are  active  in  problem-solving. 
They  also  have  knowledge  only  about  establishing  or  reject¬ 
ing  the  relevance  of  that  conceptual  entity.  Thus  they  may  be 
termed  “specialists,"  in  particular,  “diagnostic  specialists." 
The  entire  collection  of  specialists  engages  in  distributed 
problem-solving. 

The  above  account  of  diagnostic  problem-solving  is  quite 
incomplete.  We  have  not  indicated  how  multiple  diseases 
can  be  handled  within  the  framework  above,  in  particular 
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when  a  patient  has  a  disease  secondary  to  another  disease. 
Gomez  has  developed  a  theory  of  diagnostic  problem-solving 
which  enables  the  specialists  in  the  diagnostic  hierarchy  to 
communicate  the  results  of  thei:  analysis  to  each  other  by 
means  of  a  blackboard  (Erman.  Lesser,  1975),  and  how  the 
problem-solving  by  different  specialists  can  be  coordinated. 
See  (Gomez.  Chandrasekaran.  1981)  for  details.  Similarly, 
how  the  specialists  combine  the  uncertainties  of  medical  data 
and  diagnostic  knowledge  to  arrive  at  a  relatively  robust 
conclusion  about  establishing  or  rejecting  a  concept  is  an 
important  issue,  for  a  discussion  of  which  we  refer  the  reader 
to  (Chandrasekaran.  Mittal  and  Smith.  1982). 

The  points  to  notice  here  are  the  following.  The  control 
transfer  from  specialist  to  specialist  is  akin  to  the  correspond¬ 
ing  situation  in  the  medical  community.  We  shall  have  more 
to  say  about  this  later  on.  Especially  note  that  there  is  no 
"problem-solver"  standing  outside,  using  a  knowledge  base. 
The  hierarchy  of  diagnostic  specialists  is  the  problem-solver 
as  well  as  the  knowledge-base,  albeit  of  a  limited  type  and 
scope.  That  is,  the  particular  kind  of  problem-solving  is  em¬ 
bedded  in  each  of  the  units  in  the  knowledge  structure. 

Data  Retrieval  and  Inference 

Consider  the  following  situation  that  might  arise  in  diag¬ 
nostic  problem-solving  that  was  discussed  earlier.  Suppose 
a  rule  in  the  liver  specialist  was:  “If  history  of  anesthetic 
exposure,  consider  hepatitis."  This  is  a  legitimate  diagnostic 
rule  in  the  sense  described  earlier,  i.e.,  it  relates  a  manifes¬ 
tation  to  a  conceptual  specialist.  However,  suppose  there 
is  no  mention  of  anesthetics  in  the  patient  record,  but  his 
history  indicates  recent  major  surgery.  We  would  expect  a 
competent  physician  to  infer  possible  exposure  to  anesthetics 
in  this  case  and  proceed  to  consider  hepatitis.  Similarly, 
if  a  diagnostic  rule  has  "abdominal  surgery"  as  the  datum 
needed  to  fire  it,  but  the  patient  record  mentions  only  biliary 
surgery,  it  does  not  take  a  deep  knowledge  of  medicine  to  fire 
that  diagnostic  rule.  In  both  these  cases  domain  knowledge  is 
needed,  but  the  reasoning  involved  is  not  diagnostic  reason¬ 
ing  in  our  specific  technical  sense.  One  can  imagine  an  expert 
diagnostician  turning,  in  the  course  of  her  diagnostic  reason¬ 
ing,  to  a  nurse  in  charge  of  the  patient  record  and  asking  if 
there  was  evidence  of  anesthetic  exposure  or  of  abdominal 
surgery,  and  the  nurse  answering  affirmatively  in  both  the 
instances  without  his  being  trained  in  diagnosis  at  all. 

When  we  faced  this  problem  in  the  design  of  MDX.  we 
realized  that  it  would  be  very  inelegant  to  combine  reason¬ 
ing  of  this  type  with  the  diagnostic  reasoning  that  we  had 
isolated  as  a  specific  type  of  problem-solving  activity.  We 
were  led  to  the  creation  of  a  separate  subsystem  for  manag¬ 
ing  patient  data,  much  like  the  nurse  alluded  to  earlier.  For 
all  questions  concerning  manifestations.  MDX  simply  turned 
to  this  subsystem,  which  performed  the  relevant  reasoning 
and  returned  the  answer.  We  were  surprised  to  discover 
that  all  the  retrieval  activities  of  this  "data  base  assistant" 
could  be  captured  in  a  uniform  paradigm,  to  be  elaborated 


shortly.  Mittal  (Mittal.  1980)  describes  this  in  detail  as  do 
the  references  (Mittal.  Chandrasekaran.  1981)  and  (Mittal. 
Chandrasekaran.  1969).  Similar  to  our  discussion  regard¬ 
ing  the  diagnostic  task,  we  just  touch  upon  the  issues  here 
sufficient  to  make  our  main  points  regarding  decomposition. 

This  data  base-called  PATREC-is  organized  as  a  hierar¬ 
chy  of  medical  data  concepts.  A  fragment  of  the  hierarchy 
is  shown  in  Fig.  2. 

At  a  representational  level,  there  is  nothing  novel  here: 
each  medata  concept  is  represented  as  a  frame,  and  the 
inference  rules  that  we  will  describe  shortly  are  implemented 
as  “demons"  or  “procedural  attachments."  However  what 
will  be  worth  noticing  is  the  fact  that  all  these  rules  will  be 
of  a  certain  uniform  type.  For  the  purpose  of  illustration, 
let  us  consider  the  SURGERY  concept.  SURGERY  frame  has 
LOCATION  and  PERFORMED?  slots,  among  others.  The 
“PERFORMED?”  slot  has  the  following  rules: 

1.  If  no  surgery  in  the  enclosing  organ,  surgery  not 
done. 

2.  If  surgery  in  a  component,  infer  surgery  in  this  organ. 

3.  If  no  surgery  in  any  of  the  components,  then  infer  no 
surgery  in  this  organ. 

4.  If  evidence  of  anesthetic,  infer  “possibly." 

The  DRUG  frame  has  the  following  rules  in  the  GIVEN? 

slot: 

1.  If  any  drug  of  this  type  given,  infer  this  drug  also. 

2.  If  the  drug  class  was  not  given,  rule  out  this  particular 
drug. 

3.  If  all  drugs  of  this  type  were  ruled  out.  rule  out  the 
class  too. 


These  rules  need  not  be  attached  to  the  successors  of 
DRUG,  since  they  can  inherit  these  rules-this  is  a  fairly 
standard  thing  to  do  in  frame-based  systems.  A  successor 
may  have  further  rules  which  are  particular  to  it,  e.g.  the 
.ANESTHETIC  concept  has  the  rule: 

If  major  surgery,  infer  ANESTHETIC  given,  possibly. 

Let  us  reemphasize  that  the  interesting  thing  about  the 
system  is  not 

rare  knowledge  base  system  that  doesn't— but  that  it  is  a 
collection  of  conceptual  specialists  tuned  to  a  particular  type 
of  problem-solving.  All  the  embedded  inference  rules  have  a 
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common  structure:  derive  the  needed  data  value  from  data 
values  relating  to  other  concepts.  The  inferential  knowledge 
that  is  encoded  in  the  concepts  is  specific  to  the  data  retrieval 
task  in  a  data  base  activity. 

Let  us  consider  some  examples.  Suppose  the  stored 
datum  is  that  “Patient  was  given  halothane.'’  The  HALO- 
THANE  frame  now  has  its  GIVEN?  slot  filled  with  ‘Yes." 
Consider  the  following  series  of  questions: 

Ql.  Given  .Anesthetic 
A :  YES 

i  ANESTHETIC  specialist  inherits  the  rules  from  the 
DRUG  frame.  Rule  1  generates  the  question,  among 
others.  “Given  Halothane?"  “Yes"  is  propagated  up¬ 
wards.) 

Q2.  .Any  Surgery  performed? 

A  :  Possibly 

{SURGERY  specialist  fails  with  rules  1.  2  and  3.  Rule 
4  places  query  “Given  Anesthetic?"  to  ANESTHETIC 
specialist.  “Yes"  answer  results  in  “Possibly”  to  Q2.  This 
is  an  example  of  lateral  inheritance.) 

Similarly  if  the  stored  datum  were  “Patient  had  major 
surgery."  and  the  query  were.  “Given  Anesthetic?" .  rule  1  in 
ANESTHETIC  would  have  given  the  answer  “possibly." 

.Another  more  complex  example  of  data  retrieval  reason¬ 
ing  by  PATREC  is  the  following: 

DATA:  A  liver-scan  showed  a  filling  defect 
in  the  left  hepatic  lobe.  The  liver 
was  normal  on  physical  exam. 

Q  :  Liver  Normal? 

A  :  No 

I  On  liver-scan  data,  the  following  chain  of  inference 
took  place:  (a)  filling-defect  in  lobe  —  lobe  not  normal: 
fb)  If  <comp-of>  liver  not  normal  —  liver  not  nor¬ 
mal.  On  the  other  hand.  Physical  examination  produced 
“Normal"  as  answer.  By  using  a  general  principle  that 
when  there  are  contending  answers,  non-default  value 
should  be  chosen — the  default  for  “Normal?"  slot  of 
LIVER  is  “Yes" — the  answer  “No"  was  generated.) 

The  main  points  relevant  here  are.  as  in  the  case  of 
the  diagnoetic  task:  (1)  There  is  no  separation  between  a 
knowledge  base  and  a  problem-solver.  Problem-solving  is 
embedded  in  the  knowledge  structure.  (2)  .All  the  concep¬ 
tual  specialists  perform  the  same  type  of  problem-solving, 
in  this  case,  inheritance  of  data  from  other  specialists.  (3) 
Concepts  with  the  same  name,  say  LIVER,  in  the  diagnoe¬ 
tic  structure  and  the  data  retrieval  structure  have  different 
pieces  of  knowledge  and  do  different  things.  This  is  akin  to 
the  fact  that  the  LIVER  concept  of  a  diagnostician  is  bound 
to  be  different  from  that  of  the  data  base  nurse.  The  concepts 
in  this  sense  are  “tuned”  for  different  types  of  knowledge  use. 

What- Will- Happen- If  (WWHI) 

Or  Conaequence  Finding 

We  said  that  among  the  many  types  of  problem-solving 


that  take  place  in  a  knowledge-rich  domain  is  that  of  answer¬ 
ing  questions  of  the  form  “What  will  happen  if  X  is  done?” 
Examples  are:  “What  will  happen  if  valve  A  is  closed  in  this 
power  plant  when  the  boiler  is  under  high  pressure?":  “What 
will  happen  if  drug  A  is  administered  when  both  hepatitis 
and  arthritis  are  known  to  be  present?”  Questions  such  as 
this  can  be  surprisingly  complex  to  answer  since  formally  it 
involves  tracing  a  path  in  a  potentially  large  state  space.  Of 
course  what  makes  possible  in  practice  to  trace  this  path  is 
domain  knowledge  which  constrains  the  possibilities  in  an 
efficient  way. 

The  problem-solving  involved,  and  correspondingly  the 
use  of  knowledge  in  this  process,  are  different  from  that  of 
diagnosis.  For  one  thing,  many  of  the  pieces  of  knowledge 
for  the  two  tasks  are  completely  different.  For  '  mple,  con¬ 
sider  answering  the  question  in  the  automob  rr>  chanic  s 
domain:  “What  will  happen  if  the  engine  ge  ,ot?"  Look¬ 
ing  at  ail  the  diagnostic  rules  of  the  form  .  -ft  engine  — 
< malfunction >”  will  not  be  adequate,  since  alfunction> 
in  the  above  rules  is  the  cause  of  the  hot  ei  .t  hile  the 
consequence  finding  process  looks  for  the  efli  a  the  hot 
engine.  Formally,  if  we  regard  the  underlying  knowledge  as 
a  network  connected  by  cause-effect  links,  where  from  each 
node  multiple  cause  links  as  well  as  effect  links  emanate, 
we  see  that  the  search  processes  are  different  in  the  two  in¬ 
stances  of  diagnosis  and  consequence-finding.  The  diagnostic 
concepts  that  typically  help  to  provide  focus  and  constrain 
search  in  the  pursuit  of  correct  causes  will  thus  be  different 
from  the  WWHI  concepts  needed  for  the  pursuit  of  correct 
effects. 

The  embedded  problem-solving  is  also  correspondingly 
different.  We  propose  that  the  appropriate  language  in  which 
to  express  the  consequence-finding  rules  is  in  terms  of  state- 
changes.  To  elaborate: 

1 .  WWHI  -condition  is  first  understood  as  a  state  change 
in  a  subsystem. 

2.  Rules  are  available  which  have  the  form  “<  state 
change  in  subsystem  >  will  result  in  < state  change 
in  subsystem >".  Just  as  in  the  case  of  the  diagnosis 
problem,  there  are  thousands  of  rules  in  the  case  of 
any  nontrivial  domain.  Again,  following  the  diagnos¬ 
tic  paradigm  we  have  already  set.  we  propose  that 
these  rules  be  associated  with  conceptual  specialists. 

Thus  typically  all  the  state  change  rules  whose  left 
hand  side  deals  with  a  subsystem  will  be  aggregated 
in  the  specialist  for  that  subsystem,  and  the  right 
hand  side  of  those  rules  will  refer  to  the  state  changes 
of  the  immediately  affected  systems. 

.Again  we  propose  that  typically  the  specialists  be  or¬ 
ganized  hierarchically,  so  that  a  subsystem  specialist,  given 
a  state  change  to  it,  determines  by  knowledge- based  reason¬ 
ing  the  state  changes  of  the  immediately  larger  system  of 
which  it  is  a  part  and  calls  that  specialist  with  the  informa¬ 
tion  determined  by  it.  This  process  will  be  repeated  until 
the  state  changes)  for  the  overall  system,  i.e..  at  the  most 
general  relevant  level  of  abstraction,  are  determined.  This 
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form  of  organization  of  the  rules  should  provide  a  great  deal 
of  focus  to  the  reasoning  process. 

,  An  Illustrative  Example.  Consider  the  question,  in 
the  domain  of  automobile  mechanics,  “WWHI  there  is  a  leak 
in  the  radiator  when  the  engine  is  running?”  We  suggest  the 
specialists  are  to  be  organized  as  in  Fig.  3. 

The  internal  states  that  the  radiator  fluid  subsystem 
might  recognize  may  be  partially  listed  as  follows:  {leaks/ no 
leaks,  rust  build-up.  total  amount  of  water,...};  similarly,  the 
fan  subsystem  specialist  might  recognize  states  {bent /straight 
fan  blades,  looee/tight/disconnected  fan  belt,...}.  The  cool¬ 
ing  system  subsystem  itself  need  not  recognize  states  to  this 
degree  of  detail:  being  a  specialist  at  a  somewhat  higher  level 
of  abstraction  it  will  recognize  states  such  as  {fluid  flow  rate, 
cooling-air  flow  rate...etc.}.  Let  us  say  that  the  radiator  fluid 
specialist  has.  among  others,  the  following  rules.  The  rules 
are  typically  of  the  form: 

<  internal  state  change  >  —  <  supersystem  state 

change  > 

leak  in  the  radiator  —  reduced  fluid  flow-rate 
high  rust  in  the  pipes  —  reduced  fluid  flow- rate 
no  antifreeze  in  the  water 
and  verv  cold  weather  —  zero  fluid  flow  etc. 


The  cooling  system  specialist  might  have  rules  of  the 
form: 

low  fluid-flow  rate  and  engine  running  — *  engine  state  hot 
low  air-flow  rate  and  engine  running  — *  engine  state  hot 


Again  note  that  the  internal  state  recognition  is  at  the  ap¬ 
propriate  level  of  abstraction,  and  the  conclusions  refer  to 
state  changes  of  its  parent  system. 

It  should  be  fairly  clear  how  such  a  system  might  be 
able  to  respond  to  the  query  about  radiator  leak.  Again  a 
blackboard  for  this  task  would  make  it  possible  to  take  into 
account  subsystem  interaction. 

Unlike  the  structures  for  the  diagnostic  and  data  retrieval 
tasks,  we  have  not  yet  implemented  a  system  performing 
the  WWHI- task.  While  we  cannot  speak  with  assurance 
about  the  adequacy  of  the  proposed  solution,  we  feel  that 
it  is  of  a  piece  with  the  other  systems  in  pointing  to  the 
same  set  of  morals:  embedding  still  another  type  of  problem¬ 
solving  in  a  knowledge  structure,  which  consists  of  cooperat¬ 
ing  specialists  of  the  same  problem-solving  type. 
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Figure  4 

Knowledge-Use  Taxonomy 

There  has  been  a  growing  realization  in  the  field  that 
the  important  issue  in  knowledge  systems  is  to  determine 
how  knowledge  is  to  be  used.  Our  foregoing  examination  of 
the  three  tasks — each  of  which  is  not  some  ad  hoc  need  for 
medical  reasoning,  but  is  a  generic  task  that  arises  in  a  num¬ 
ber  of  domains — leads  us  to  propose  the  following  theses. 

1.  There  is  taxonomy  of  problem-solving  regimes  that 
are  involved  in  expert  problem-solving.  We  have 
identified  three  members  of  this  taxonomy 

•  diagnostic  (classificatory):  establish- refine,  top- 
down. 

•  consequence-finding:  abstract  state  from  low-level 
description  to  higher-level  description,  bottom-up. 

•  data  retrieval:  inheritance/inference  of  values  from 
data  values  in  other  concepts. 

There  are  obviously  more.  Our  research  is  oriented 
towards  finding  more  elements  of  this  taxonomy  and 
determining  their  interrelationships. 

2.  For  each  type  of  problem-solving  there  is  a  separate 
knowledge  structure,  with  the  associated  ps.  regime 
embedded  in  it.  Thus  a  domain  of  knowledge  can  be 
decomposed  into  a  collection  of  structures,  each  of 
which  specializes  in  a  p.s.  type.  We  can  call  this  a 
horizontal  decomposition  of  the  domain. 

3.  Each  of  the  structures  in  (2)  above  can  be  further 
decomposed  into  a  collection  of  specialists,  all  of 
whom  are  of  the  same  p.s.  type,  but  differ  from  each 
other  in  the  conceptual  content.  We  have  indicated 
how  this  decomposition  can  be  done  for  the  three 
tasks  considered.  We  term  this  decomposition  a  ver¬ 
tical  decomposition. 


A  Paradigm  Shift 

The  prevalent  approach  to  knowledge  base  systems  is 
based  on  the  decomposition  in  Fig.  4: 

In  this  paradigm,  knowledge  representation  is  separated  from 
its  use.  This  approach  has  the  attraction  of  generality  and 
a  certain  kind  of  modularity. 

The  representational  questions  are  dealt  with  in  this 
approach  in  a  manner  to  satisfy  the  criterion  of  expres¬ 
siveness,  or  so-called  epistemological  adequacy  of  McCarthy 


(McCarthy,  Hayes,  1969).  The  efficiency  responsibilities  are 
put  on  the  shoulders  of  the  inference  mechanisms:  they  have 
to  have  the  so-called  heuristic  knowledge  in  order  to  use  the 
knowledge  efficiently  for  problem-solving.  Our  approach  is 
based  on  a  rather  different  decomposition  of  the  3ame  prob¬ 
lem,  as  indicated  in  our  discussion  on  horizontal  decomposi¬ 
tion  in  the  previous  section. 

Pictorially,  the  viewpoint  of  knowledge-based  systems 
that  we  advance  can  be  given  as  Fig.  5. 

Thus  the  overall  knowledge  system  is  viewed  as  a  collec¬ 
tion  of  specialists  in  inference  types,  who  cooperatively  solve 
a  given  problem.  While  in  the  figure  we  have  indicated  the 
communication  among  these  specialists  to  be  unconstrained, 
in  fact,  however,  it  may  not  be  so.  There  may  be  reasons 
why  only  certain  problem-solving  specialists  can  talk  to  other 
problem-solving  specialists.  This  is  an  open  research  prob¬ 
lem  in  our  approach. 

Production  Rule  Methodology.  In  most  of  the 
preceding  discussions  the  representation  of  knowledge  has 
been  in  the  form  of  rules.  We  feel  that  this  is  not  acciden¬ 
tal,  but  that  rules  represent  a  basic  form  of  cognition,  viz., 
“how-to”  knowledge.  This  was  recognized  early  in  AI  by 
Newell  and  Simon  (Newell,  Simon,  1972)  who  named  the 
rules  production  rules.  Later,  the  Stanford  Heuristic  Pro¬ 
gramming  Project  and  others  extended  this  production  rule 
methodology  for  a  wide  class  of  expert  system  design  prob¬ 
lems.  We  are  thus  in  agreement  with  the  use  of  rules  as  a 
basic  knowledge  representation  formalism  in  expert  systems. 

There  are  two  aspects  in  which  our  methodology  differs 
from  current  work  on  rule  based  systems.  We  have  already 
alluded  to  the  difference  in  the  viewpoint  which  regards 
knowledge  not  as  an  independent  structure  to  be  used  by 
different  problem-solvers,  but  as  embodiments  of  implicit 
problem  solving  knowledge.  Related  to  that  is  the  idea  that 
the  central  determinant  of  effective  use  of  knowledge  is  how 
it  is  organised.  Our  approach  begins  to  provide  criteria  for 
performing  the  organization  of  a  complex  body  of  knowledge. 
It  is  well-known  that  production  rules  need  to  be  organized 
not  simply  for  purpose  of  efficiency,  but  for  focus  and  control 
in  problem-solving  (see  (Lenat,  Harris,  1978)  for  a  discussion 
of  these  issues).  We  are  proposing  two  organizing  constructs, 
which  extend  the  production  rule  methodology  to  make  it 
applicable  to  a  larger  class  of  problems.  One  construct  is  the 
problem-solving  regime  and  the  other  is  that  of  a  conceptual 
specialist. 

Related  to  these  organizational  notions  is  the  other 
aspect  of  the  difference  between  our  approach  and  the 
current  production  rule  methodologies.  We  do  not  use 
uniform  problem-solving  mechanisms  (backward  chaining, 
e.g.)  across  the  whole  domain.  .As  indicated,  the  problem¬ 
solving  method  differs  from  knowledge  structure  to  knowledge 
structure. 
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Role  of  “Deep”  Models 

Deep  and  Compiled  Structures.  Recently  Hart 
(Hart,  1982)  and  Michie  (Michie,  1982)  have  written  about 
the  “depth”  at  which  knowledge  is  represented  and  used 
in  problem  solving  by  expert  systems.  Distinctions  such  as 
“deep”  vs  “surface”  and  “high  road"  vs  “low  road”  have  been 
made  in  this  connection.  There  is  no  clear  definition  of  what 
constitutes  a  deep  model  -  in  fact  precisely  that  issue  is  an 
open  area  of  research  in  the  field,  but  the  intuition  is  that 
it  models  the  underlying  processes  of  the  domain.  Michie 
remarks  that  most  expert  systems  that  are  extant  don’t  have 
deep  models  in  this  sense,  but  instead  can  be  viewed  as  a  data 
base  of  patterns  with  a  more  or  less  simple  control  structure 
to  navigate  through  the  data  base.  It  is  argued  that  surface 
systems  of  this  type  have  inherent  limitations  in  hard  prob¬ 
lems,  and  that  a  system  which  has  a  deep  model  will  be  able 
to  turn  to  it  when  faced  with  an  especially  knotty  problem, 
much  like  a  human  expert  might  resort  to  “first  principles”  in 
a  similar  situation.  In  addition  to  deep  models  of  the  domain, 
the  human  problem  solver  also  uses  other  sorts  of  knowledge 
such  as  “common  sense"  knowledge  of  various  kinds. 

In  the  rest  of  the  discussion  in  this  section  we  will  ex¬ 
plicitly  consider  the  diagnostic  task  only.  But  the  arguments 
will  apply  to  other  tasks  as  well. 

We  argue  in  (Chandrasekaran,  Mittal,  1982)  for  a  thesis 
which  might  at  first  sound  counter-intuitive.  Let  us  assume 
that  we  wish  to  design  a  diagnostic  system  in  a  particular 
domain.  Let  us  further  assume  that  we  can  successfully 
construct  a  deep  model  of  the  domain,  and  also  specify  the 
problem  solving  processes  that  will  operate  on  that  model. 
The  thesis  that  we  argue  in  (Chandrasekaran,  Mittal,  1982) 
is  as  follows.  Between  the  extremes  of  a  data  base  of  pat¬ 
terns  on  one  hand  and  representations  of  fdeep  knowledge 
(in  whatever  form)  on  the  other,  there  exists  a  knowledge 
and  problem  solving  structure  -  alon-*  the  lines  outlined  in 
the  section  on  the  diagnostic  task  in  this  paper  -  which  ( 1 ) 
has  all  the  relevant  deep  knowledge  “compiled”  into  it  in 
such  a  way  that  it  can  handle  all  the  diagnostic  problems 
that  the  deep  knowledge,  if  explicitly  represented  and  used 


in  problem-solving,  can  handle;  and  (2)  will  solve  the  diag¬ 
nostic  problems  more  efficiently  than  the  deep  structure  can: 
but  (3)  it  cannot  solve  other  types  of  problems-  i.e.,  problems 
which  are  not  diagnostic  in  nature  -  that  the  deep  knowledge 
structure  potentially  could  handle.  The  argument  is  rather 
detailed,  but  the  essence  of  it  consists  of  analyzing  the  ways 
in  which  the  diagnostic  structure  may  fail  to  solve  a  par¬ 
ticular  problem,  and  tracing  that  failure  to  either  missing 
knowledge  in  the  deep  model  itself  or  in  the  problem  solving 
processes  that  operate  on  it.  Thus  the  range  of  diagnostic 
problems  that  can  be  solved  with  the  deep  model  is  exactly 
coextensive  with  the  problems  solvable  with  the  diagnostic 
problem  solving  structure  that  can  be  derived  from  it. 

There  is  another  way  of  looking  at  this.  There  is  a 
natural  decomposition  in  the  problem  solving  responsibilities 
between  the  underlying  knowledge  structures  and  the  diag¬ 
nostic  structure.  The  former  builds  the  diagnostic  structure 
and  the  latter  solves  specific  diagnostic  problems.  Human 
experts  often  resort  to  deep  models  because  the  diagnostic 
structures  are  in  general  incomplete.  This  decomposition 
also  translates  into  a  natural  division  of  responsibility  for 
explanation  of  decisions.  See  (Chandrasekaran,  Mittal.  1982) 
for  more  discussion  on  this. 

Multiple  Uaes  of  Knowledge.  It  is  possible  that  there 
will  be  some  redundancy  in  knowledge  represented  in  our  ap¬ 
proach,  since  it  calls  for  knowledge  to  be  encoded  in  a  prob¬ 
lem  solving  structure  according  to  its  usage  -  some  pieces  of 
knowledge  may  appear  in  several  structures.  (See  comments 
in  (Gomez,  Chandrasekaran.  1981)  on  redundancy  and  bias¬ 
ing  of  knowledge.)  Is  this  a  good  thing? 

We  have  a  choice:  (1)  We  can  have  the  knowledge  in 
a  deep  enough  form,  but  as.  say.  a  diagnostic  problem 
presents  itself,  we  can  first  generate  fragments  of  diagnos¬ 
tic  knowledge  as  needed  and  use  it  to  solve  the  given  prob¬ 
lem.  Similarly  for  a  WWHI  problem,  etc.  Or,  (2)  we  can 
choose  the  tasks  to  be  experts  in  ,  compile  the  problem  solv¬ 
ing  structures  for  them,  accepting  some  redundancy.  The 
latter  is  faster  for  those  tasks  for  which  they  are  designed, 
the  former  is  more  economical  in  storage.  A  classic  trade-off! 
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In  a  sense  the  former  situation  describes,  e.g.,  a  bright 
medical  school  graduate  who  has  a  functional  understanding 
of  the  phenomena  of  the  human  body,  but  that  knowledge 
is  not  yet  molded  into  effective  problem  solving  structures  of 
particular  types.  We  suspect  that  what  happens  even  among 
experts  is  that  they  build  powerful  problem  solving  struc¬ 
tures  to  account  for  a  good  portion  of  foreseeable  situations, 
and  thus  need  to  resort  to  the  deeper  structures  only  for  the 
harder  problems.  This  is  a  compromise  between  the  require¬ 
ments  of  expertise  and  memory. 

The  Nature  of  the  Deep  Model 

There  is  an  additional  problem  with  option  1  in  the 
current  state  of  the  art:  we  don't  know  how  to  do  it!  This 
requires  an  adequate  theory  of  the  nature  of  the  deep  model. 
When  a  person  newly  understands  how  a  device  works,  e.g., 
it  is  doubtful  that  what  he  has  acquired  is  merely  a  collection 
of  rules  or  facts,  or  a  network  of  causal  relations.  One 
can  have  all  these  and  still  not  “understand.’1  The  sense 
of  understanding  must  correspond  to  some  organization  of 
these  pieces  of  knowledge  for  some  class  of  purposes.  The 
organization  must  be  such  that  it  can  be  processed  to  produce 
problem  solving  structures  for  various  tasks.  The  nature  of 
the  deep  model  is  an  extremely  important  area  of  research. 
The  work  of  (Rieger,  Grinberg,  1976),  (Pople,  1982),  (Patil, 
1981 )  and  (de  Kleer,  Brown,  1982),  to  name  a  few  researchers 
who  have  looked  at  this  problem,  seem  very  relevant  here. 
However,  in  order  to  adequately  represent  knowledge  at  this 
level,  notions  of  an  organizational  nature  particular  to  that 
level  also  seem  important. 

On  Hierarchies 

In  all  the  tasks  that  we  considered  in  this  paper,  the 
knowledge  structures  were  strongly  hierarchical.  While 
hierarchical  organizations  have  a  strong  intuitive  appeal,  in 
AI  there  is  also  a  strong  tradition  of  “heterarchies”  and  net¬ 
work  structures.  Difficulties  with  hierarchical  classification 
structures  have  been  noted  in  (Fahlman,  et  al,  1981).  Also 
concerns  such  as  “the  world  is  not  hierarchical"  are  voiced 
in  response  to  proposals  for  hierarchical  organizations. 

This  is  not  the  place  to  discuss  the  important  issue  of 
hierarchical  structures  in  problem  solving.  The  following 
brief  remarks  should  suffice  for  our  purposes.  First  of  all, 
the  main  thesis  about  decomposing  knowledge  by  problem 
solving  types  and  embedding  of  the  problem  solving  in  the 
knowledge  sources  is  itself  independent  of  whether  the  struc¬ 
tures  for  a  problem  solving  type  are  hierarchical.  Secondly, 
our  general  strategy  has  been  to  start  by  looking  for  hierar¬ 
chical  decompositions,  and  where  there  seems  to  be  a  need 
for  communication  outside  of  the  hierarchical  channels,  to 
provide  it  in  a  carefully  controlled  fashion  such  as  the  black¬ 
boards  discussed  in  (Gomez.  Chandrasekaran.  1981).  (See 
( Chandrasekaran,  1981)  for  a  discussion  of  different  kinds 


of  communication  needs  in  a  distributed  problem  solving 
situation.)  For  example,  in  (Gomez.  Chandrasekaran.  1981) 
we  discuss  how  certain  kinds  of  relations  between  disease 
hypotheses  belonging  to  different  portions  of  the  hierarchy 
-  such  as  disease  A  being  secondary  to  disease  B  -  can  be 
handled  within  a  hierarchical  framework  by  the  use  of  black¬ 
boards.  Finally,  it  ought  to  be  stated  clearly  that  hierarchies 
are  not  “out  there.”  but  imposed  by  the  thought  processes 
for  control  over  problem  solving.  Thus  it  is  a  powerful 
weapon,  but  by  no  means  a  sufficient  one.  It  will  be  rash 
to  conclude  that  ail  complex  problem  solving  in  ali  com¬ 
plex  domains  can  be  crisply  conducted  in  a  single  hierar¬ 
chical  framework.  Reasoning  about  feedback  and  reason¬ 
ing  with  multiple  perspectives  are  two  examples  where  addi¬ 
tional  machinery  seems  to  be  needed  beyond  the  hierarchical 
framework. 


The  Organization  of  the  Medical  Community 

Evidence  of  Horizontal  Decomposition.  The  medi¬ 
cal  community  collectively  is  a  good  case  study  in  the  prin¬ 
ciples  by  which  knowledge  may  be  structured  for  cooperative, 
effective  problem-solving.  Corresponding  to  our  notion  of 
horizontal  decomposition  along  the  lines  of  problem-solving 
types,  we  can  identify  clinicians,  educators,  pathologists, 
radiologists,  medical  records  specialists,  etc.  Clinicians  com¬ 
bine  the  diagnostic  and  predictive  knowledge  structures,  for 
practical  reasons  having  to  do  with  the  close  interaction 
between  diagnosis  and  therapy.  Medical  record  specialists, 
as  their  name  indicates,  serve  to  organize  patient  data  and 
retrieve  them  effectively.  Radiologists  are  not  diagnosticians 
in  the  same  sense  as  clinicians  are:  their  problem-solving  is  to 
reason  from  imaging  descriptions  to  confirm  or  reject  diag¬ 
nostic  possibilities:  they  are  largely  perceptual  specialists. 

Evidence  of  Vertical  Decomposition.  Correspond¬ 
ing  to  our  vertical  decomposition,  many  of  the  above  problem- 
solvers  are  organized  into  conceptual  hierarchies.  For  in¬ 
stance,  an  internist  is  the  top-level  diagnostic  specialist,  who 
may  call  upon  liver  or  heart  specialists  for  further  investiga¬ 
tion  of  a  problem.  The  top-down  problem-solving  for  diag¬ 
nosis  is  indicated  by  the  fact  that  a  sick  person  typically  first 
goes  to  an  internist,  who  may  refer  the  patient  on  to  more 
detailed  specialists. 

Evidence  for  Embedding  Problem-Solving.  If  the 
medical  community  were  organized  according  to  the  cur¬ 
rently  accepted  paradigm  in  expert  systems,  i.e..  a  com¬ 
mon  knowledge  base  shared  by  different  problem-solvers  who 
themselves  are  without  domain-knowledge,  one  would  ex¬ 
pect  to  have  knowledge-specialists,  who  would  be  rather  like 
encylopaedias.  and  problem-solving  specialists  who  would 
possess  expert-algorithms  for.  say,  diagnosis,  without  any 
medical  knowledge  about  particular  medical  concepts.  Thus 
whenever  a  patient  came,  the  diagnostic  specialist  would  con¬ 
sult  the  knowledge-base  specialist  and  together  they  would 
arrive  at  a  diagnostic  conclusion. 
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However,  that  is  not  the  way  the  community  works.  In¬ 
stead  we  find  that  experienced  medical  specialists  possess 
expertise  which  is  not  a  raw  knowledge-base,  but  which 
is  highly  effective  in  problem-solving.  On  the  other  hand, 
a  medical  student  without  clinical  experience  is  more  like 
a  pure  knowledge-base.  As  he  or  she  becomes  more  ex¬ 
perienced  in  various  types  of  problem-solving,  the  unstruc¬ 
tured  knowledge  base  slowly  begins  to  shape  and  structure 
itself,  so  that  pieces  of  knowledge  are  tuned  for  ready  and 
effective  use. 
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Abstract 


Ve  present  an  approach  to  expert  systems  for 
mechanical  design  called  Design  Refinement,  which 
addresses  a  subset  of  design  activity  by  using  a 
hierarchy  of  conceptual  specialists  that  solve  the 
design  problem  in  a  distributed  manner,  top-down, 
choosing  from  sets  of  design  plans  and  refining  the 
design  at  each  level  of  the  hierarchy. 


1*  Introduction 


In  terms  of  economic  impact,  one  of  the  most 
important  areas  for  AI  technology  is  CAD/CAM.  AI 
is  applicable  to  a  variety  of  subtasks  in  CAD/CAM: 
process  control  and  robotics  are  areas  where  work 
has  already  been  done.  However,  in  terms  of 
intellectual  difficulty  the  central  problem  is 
design  itself.  While  much  Al-related  work  is  being 
done  in  the  creation  of  design  aids  in  the  VLSI 
area  9,10,11 ^  there  has  been  relatively  little 
attention  paid  to  the  knowledge  structuring  and 
problem  solving  issues  in  the  main  problem  of 

design  itself.  This  paper  addresses  the  problem  of 
expert  systems  for  mechanical  design.  For  an 

important  class  of  design  tasks,  ve  present  an 

approach  with  design  refinement  as  the  central 
problem  solving  activity.  This  activity  can  be 

quite  complex,  but  our  aim  here  is  to  provide  a 
first-cut  analysis  of  this  process  in  order  to  show 
it's  potential  for  generating  design  expert 
systems . 


Currently  on  leave  from  the  Department  of 
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The  creation  of  computer-based  expert  consultants 
in  any  area  of  human  endeavour  requires  an  analysis 
both  of  the  knowledge  structures  that  the 
corresponding  human  specialist  uses,  and  the 
problem-solving  methods  that  underlie  the  different 
tasks.  Thus  much  of  our  discussion  will  be  taken 
up  with  an  account  of  these  aspects  of  the  design 
process . 


2.  Types  of  problem  solving 


We  have  been  developing  a  framework  for 
decomposing  a  complex  body  of  knowledge  into  small 
knowledge  sources,  and  organizing  them  into  a 
structure  of  specialists  engaged  in  collective 
problem  solving.  We  have  identified  several 
distinct  types  of  problem  solving  that  are  useful 
in  the  design  of  expert  systems  ^ .  One  advantage 
of  this  is  that  it  enables  one  to  characterize 
which  kinds  of  expert  problem  solving  we  know  how 
to  mechanize. 

One  type  of  problem  solving  is  capable  of 
performing  diagnosis,  i.e.,  capable  of  reasoning 
about  how  to  classify  a  complex  description  of 
reality  as  a  node  in  a  diagnostic  hierarchy  1 . 
Another  type  of  problem  solving  (called  WVHI  by  us) 
is  capable  of  reasoning  about  consequences  of 
contemplated  actions  on  complex  systems,  such  as 
answering  the  question,  "What  will  happen  if  1 
close  that  valve  in  this  power  plant?".  We  believe 
that  design  can  be  classified  as  a  distinct  type  of 
problem  solving,  and  that  it  is  different  from  the 
other  types  we  have  identified.  We  will  outline  how 
a  community  of  design  specialists  can  work  together, 
to  convert  a  list  of  specifications  for  a  component 
into  a  detailed  design  for  that  component. 


3.  Discussion  of  design  activity  in  general 


In  general,  design  is  a  highly  creative  activity, 
the  underpinnings  of  which  we  in  AI  only  dimly 
perceive.  Often  the  design  goals  themselves  are 
only  vaguely  specified,  and  the  feedback  from 
attempts  to  achieve  these  goals  serves  to  modify 
them.  Thus  designers  of  new  systems  work  with 
knowledge  structures  and  problem  solving  techniques 
that  we  cannot  yet  adequately  capture  with  AI 
technology.  What  the  current  state  of  the  art  in 
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AI  can  do  for  them  is  more  along  the  lines  of 
support  systems  (intelligent  graphic  aids, 
knowledgeable  data  bases,  etc.),  rather  than 
actually  performing  the  design  task  itself  13,5  # 

In  a  typical  industrial  operation,  however,  the 
daily  task  of  the  designer  is  frequently  less 
exalted  than  the  kind  of  highly  creative  design 
mentioned  above.  In  fact,  most  industries  perform 
design  tasks  which,  for  the  purposes  of  the  current 
discussion,  can  be  classified  into  roughly  three 
categories  (to  simplify  what  really  is  a  spectrum 
from  the  most  open  ended  to  the  most  routine). 

Class  1  design  is  done  so  rarely  it  is  often  the 
basis  of  a  naw  company,  division  or  a  major 
marketing  effort.  Major  inventions  belong  to  this 
category.  The  design  activity  in  this  case 
involves  access  to  wide-ranging  knowledge 
structures,  and  searches  in  a  very  large  space  of 
design  alternatives. 

Class  2  design  is  closer  to  the  routine,  but 
still  many  of  the  established  patterns  may  be 
broken.  Some  aspects  of  design  may  require 
substantial  innovation;  e.g.,  in  a  company  which 
manufactures  integrated  sensor  systems  for  control 
of  sheet  processes,  the  need  to  take  into  account 
extremely  hot  aa&ient  conditions  for  a  particular 
order  may  require  suspension  of  the  standard  design 
and  launching  of  an  investigation  about  nev  (for 
the  company)  techniques  of  control  of  ambient 
testperature  within  the  sensor  housing,  which  might 
in  turn  result  in  new  sealing  techniques  and  so  on. 
In  many  companies,  this  happens  periodically,  but 
is  undertaken  with  the  hope  that  the  investment  of 
time  and  energy  will  be  paid  off  by  identifying  a 
potentially  large  market,  in  which  the  new  elements 
of  design  can  be  "routinized". 

Class  3  design,  the  most  routine,  follows  a  set 
of  relatively  well-established  design  alternatives 
which  are  reasonably  well-understood,  but 
nevertheless  still  require  a  well-trained  human 
expert  to  perform  the  design  task.  He  do  not 
intend  to  imply  that  the  task  is  "simple";  in  fact, 
we  cannot  fully  substitute  for  the  human  expert, 
and  nev  advances  in  AI  are  called  for.  For 
example,  simple  approaches,  such  as  use  of  a 
data-base  of  design  parameters  with  associated 
designs,  may  work  for  some  problems,  but  in  general 
they  will  fail  due  to  the  large  number  of 


combinatorial  possibilities. 


Let  us  examine  in  some  further  detail  the  nature 
of  Class  3  design  tasks.  There  exists  a  large 
number  of  industries  which  make  one-of-a-kind 
products,  where  each  is  of  the  same  general  class. 
For  example,  AccuRay  Corporation,  our  collaborator, 
designs  and  delivers  control  systems  to  industries 
which  manufacture  sheet  products  (aluminum  foil, 
paper,  etc.).  These  control  systems  have  sensors 
which  continually  monitor  various  properties  of  the 
sheets,  and  provide  the  signals  which  can  be  used 
to  keep  the  thickness  within  certain  bounds. 
However,  even  within  one  industry,  no 
pre-cons true ted  system  can  be  placed  within  a 
functioning  mill.  Each  control  system  is  built 
anev  from  specifications  that  are  gathered  from  a 
particular  prospective  installation.  The  control 
system  itself  is  complex  and  consists  of  the  sensor 
assembly  (frame,  carriage,  sensors,  etc.)  and  the 
complex  computing  system  (minicomputers  and 
software)  that  goes  with  the  sensor  hardware. 

The  complexity  of  the  task  arises  from  the 
numerous  subcomponents  and  their  sub-subcomponents, 
each  of  which  needs  to  be  specified  according  to 
top-level  specifications.  The  top-level 
specifications  of  two  different  plants  in  the  same 
industry  differ  considerably,  and  this  adds  to  the 
complexity.  For  example,  no  two  paper  mills  are 
alike,  they  themselves  having  been  designed  to  the 
differing  specifications  that  arise  from  the 
differing  products  and  markets  of  the  companies. 
Numerous  constraints  exist  among  the  parameters  of 
the  subcomponents,  contributing  further  to  the 
complexity  of  the  task. 

While  a  Class  3  design  may  still  be  conceptually 
complex,  the  design  alternatives  at  each  stage  are 
not  as  open-ended  as  in  some  of  the  stages  of  Class 
2  or  Class  1  designs,  nor  is  there  the  vagueness 
and  nonoperationalism  of  the  top-level  goals  or  the 
difficulty  with  identification  of  constituent 
substructures  that  is  characteristic  of  Class  1 
design.  That  is,  despite  complexity,  the  design  is 
intellectually  more  manageable,  and  the  variety  of 
knowledge  sources  that  are  accessed  during  the 
execution  of  the  task  are  relatively  small  and  can 
be  identified  in  advance. 

Sometimes,  however,  a  design  that  had  been 
classified  as  Class  3  might  turn  out  during  the 
design  process  to  possess  many  Class  2  features . 
This  happens  if  the  design  alternatives  for  a 
certain  stage  all  fail,  and  an  exploratory  search 
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for  a  completely  new  alternative  needs  to  be 
launched.  Identifying  a  design  task  in  advance  as 
Class  3  is  a  nontrivial  problem.  But  generally, 
experienced  designers  can  judge  if  a  project  is 
Class  3  or  not. 

We  propose  that  there  is  a  very  specific  type  of 
problem  solving  associated  with  expert  design 
activity,  especially  of  the  Class  3  type:  a 
hierarchy  of  conceptual  "specialists "  solve  the 
design  problem  in  a  distributed  manner,  top-down, 
by  choosing  from  a  set  of  design  plans  and  refining 
the  design  at  each  stage.  Each  refinement  is  done 
by  a  specialist  calling  its  subspecialists  in  the 
hierarchy. 


4.  Class  3  Design 


4.1  Description  of  Class  3  Design 


S* 


r 


In  general,  the  component  to  be  designed  will  be 
quite  complex,  with  its  own  subsystems  and 
substructures.  We  propose  that  the  expert  system 
to  design  the  component  be  conceived  as  a 
hierarchical  collection  of  design  specialists, 
where  the  top  levels  of  the  hierarchy  are 
specialists  in  more  global  subsystems  of  the 
component,  while  those  at  the  lower  levels  deal 
with  more  specific  subsystems  or  parts.  They  all 
access  a  design  specification  data-base. 
Intelligent  data-base  assistants  can  play  an 
important  role  here;  for  a  discussion  see  * . 

At  each  stage  a  specialist  S  has  several 
prioritized  alternative  design  plans.  The 
specialist  begins  by  inheriting  some  design 
parameters  from  its  parent  specialist,  and  it 
obtains  relevant  specifications  from  the  data-base. 
Each  of  the  plans  can  take  these  data  as  arguments. 
Parts  of  a  plan  may  indicate  immediately  that 
constraints  cannot  be  satisfied.  This  is 
considered  as  'failure'.  Parts  of  a  plan  access 
functions  which  can  fill  in  the  design  templates 
independently,  parts  produce  further  values  or 
constraints  to  be  passed  on  to  particular 
successors,  while  other  parts  of  a  plan  give 
specific  sequences  in  which  the  successors  may  be 
invoked.  Thus,  S  fills  in  some  of  the  design,  then 
calls  its  successors  in  a  given  order  with  requests 
for  refinement  of  the  design  of  a  substructure.  If 


some  of  Che  substructures  are  independent  of  each 
other,  then  subspecialists  may  be  invoked  in 
parallel.  The  overall  global  plan  of  the 
specialist,  prioritizes  each  subplan,  invokes 
alternate  plans  in  case  of  failure  by  one  of  the 
subspecialists,  etc.  When  a  specialist  receives 
failure  from  one  or  more  of  its  successors  fo:  all 
its  plans,  or  when  failure  for  given  constraints 
can  be  deduced  immediately,  the  specialist 
communicates  that  to  its  parent.  The  exceptions  to 
this  design  refinement  structure  are  the  tip  node 
specialists  who  can  only  fill  in  the  design 
details.  Typically  as  one  goes  dovn  in  the 
hierarchy,  there  are  fever  alternative  plans,  and 
the  plans  themselves  becomes  more  straightforward. 

Let  us  consider  a  concrete,  but  highly  simplified 
example  for  illustrative  purposes  —  the  design  of 
a  Small  Table  consisting  of  a  circular  Top  and  a 
cylindrical  Support.  In  a  design  specification  the 
user  may  specify  to  the  design  system  the  materials 
to  be  used,  or  the  required  dimensions.  The 
hierarchy  of  specialists  for  the  expert  system  to 
design  the  Small  Table  is  shown  in  figure  1.  Note 
that  the  hierarchy  need  not  be  a  strictly 
component-subcomponent  hierarchy,  and  could  be 
organized  according  to  function. 


System  Organization: 


SmallTableDesigner 

Data-Bases 

/ 

\ 

< - >  /  \ 

/ 

\ 

/  \ 

/ 

\ 

Materials  Parts 

TopDesigner 

Support 

& 

Designer 

Structure 

Figure  1  :  Hierarchy  of  Specialists 


The  design  process  starts  at  SmallTableDesigner , 
at  the  point  where  the  overall  requirements  are 
given  to  the  design  system.  Consider  the  case  in 
which  SmallTableDesigner  chooses  its  first  plan, 
calls  TopDesigner,  which  in  turn  also  chooses  its 
first  plan,  does  the  design  of  the  Top,  and  returns 
the  dimensions  to  its  parent.  Now 


SmallTableDesigner  calls  SupportDesigner .  Nov 
suppose  chat  this  specialist's  only  plan  fails  to 
generate  a  successful  design  within  the 
constraints;  i.e.,  the  strength  requirement  and 
dimension  constraints  are  not  reconcilable 
according  to  its  expertise.  This  would  cause 
'failure'  to  be  returned  to  SmallTableDesigner . 
SmallTableOesigner  then  calls  TopDesigner  again 
with  a  further  constraint  about  the  weight  that  is 
permitted.  Nov  TopDesigner  will  invoke  its  second 
plan  (which  is  a  more  expensive  plan  to  execute), 
and  some  information  about  the  new  Top  design  is 
passed  to  SupportDesigner  through  its  parent 
SmallTableDesigner,  causing  SupportDesigner  to 
succeed,  and  the  design  to  succeed. 

An  important  thing  to  note  is  that  very  large 
numbers  of  designs  are  encoded  in  an  economical  way 
in  this  approach.  While  plans  are  "pre-compiled", 
actual  designs  aren't  —  they  are  actually 
generated  during  problem  solving.  Further,  the 
expertise  of  each  specialist  can  be  selectively 
increased  by  carefully  integrating  new  plans  into 
the  specialist.  Finally,  the  human  designer  can 
find  causes  of  failure  in  the  feedback  from  the 
expert  system,  and,  for  example,  might  be  able  to 
come  up  with  a  "new"  way  to  design  the  support,  so 
that  the  rest  of  the  system  can  proceed  on  a  more 
automatic  design. 

What  makes  Class  3  but  not  Class  2  or  Class  1 
amenable  to  this  approach  is  the  fact  that  in  Class 
3  projects,  a  clear  idea  of  the  identities  of  the 
specialists  in  the  hierarchy  is  available  (in  Class 
1,  one  doesn't  even  know  who  the  successors  might 
be  for  a  specialist),  and  further,  the  alternative 
plans  of  each  specialist  can  be  identified  and  are 
relatively  small  in  number  (in  Class  2,  the  needed 
alternative  design  plans  are  not  specified). 


The  role  of  analytic  routines 


The  image  of  the  designer  sitting  in  front  of  the 
CAD  graphics  terminal,  running  stress  analysis 
routines  and  visually  inspecting  the  stress 
patterns  of  a  component  is  typical  in  descriptions 
of  how  CAD  systems  work.  Analysis  of  design  is  an 
intrinsic  part  of  the  total  design  process,  but 
what  role  does  such  analysis  play  in  expert  systems 
for  Class  3  design? 


The  preceding  description  of  how  the  plans  work 
has  been  at  too  high  a  level  to  bring  out  this 
aspect.  In  fact,  analysis  of  design  plays  a  role 
in  several  steps  of  the  process.  When  a  specialist 
inherits  design  constraints  from  its  parent, 
accesses  specification  data  from  the  data  base  and 
decides  if  there  are  any  obvious  difficulties  in 
proceeding  with  the  design,  one  of  the  options  will 
be  to  run  some  analysis  packages.  Similarly,  at 
any  stage  in  the  choice  of  values  for  a  design,  the 
plan  may  call  for  some  analysis.  The  only 
difference  from  the  current  CAD  practice  is  that 
the  analysis  and  evaluation  will  be  under  the 
control  of  the  specialist's  plans. 


5.  Prototype  system 


5.1  Introduction  to  Prototype  System 


A  prototype  design  expert  system  has  been 
implemented  for  the  domain  example  used  above  — 
that  of  a  Small  Table  which  consists  of  a  circular 
Top  and  a  cylindrical  Support.  As  above,  the  design 
hierarchy  consists  of  a  Small  Table  specialist  that 
uses  a  Top  specialist  and  a  Support  specialist. 
The  system  has  a  small  design  data-base  with 
information  about  dimensions  of  parts,  the 
structure  of  the  table,  and  the  types  of  materials 
available  for  use.  Figure  2  shows  the  information 
that  a  specialist  has  available. 


Passed  Down  Constraints 


Plana  _ 

Constraints 
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Pass  Down  Constraints 
(  to  other  Specialists  ) 


Figure  2  :  Overview  of  Specialist 


Each  design  specialist  has  a  set  of  built-in 
constraints  that  specify  what  has  to  be  true  in 
order  for  that  specialist  to  complete  its  design, 
and  a  collection  of  plans  that  can  be  selected  for 
design,  redesign,  or  verification  of  an  existing 
design.  Redesign  is  the  alteration  of  an  existing 
design  due  to  the  estab?  Lshment  of  new 
specifications.  As  this  is  a  class  3  task,  each 
specialist  has  fixed  plans  that  approach  the  design 
task  at  that  level  of  the  hierarchy  in  some 
prespecified  manner.  Each  specialist  has  a  'plan 
suggester'  that  selects  the  plan  to  be  executed. 

The  system  is  started  by  giving  the  Small  Table 
designer  the  user's  design  specifications  —  for 
example,  that  the  top  be  Marble.  When  a  specialist 
calls  a  sub-specialist  all  relevant  constraints 
from  the  user's  specification  are  passed  down.  A 
specialist  succeeds  when  its  selected  plan 
succeeds,  and  that  can  only  happen  when  its 
built-in  and  passed-down  constraints  are  satisfied. 
The  system  uses  default  values  to  do  'rough' 
design,  and  can  make  small  refinements  to  those 
values  if  necessary  in  order  to  satisfy 
constraints.  The  'trace'  of  the  system  is  very 
readable,  with  checking  and  decisions  being  handled 
in  appropriate  places.  The  flow  of  control  in  the 
system  is  well  disciplined  and  it  is  clear  at  each 
step  what  part  of  the  design  is  being  attempted  and 
why. 


5.2  Structure 


Specialists  The  specialists  in  the  system  are 
represented  by  a  list  of  attribute-value  pairs, 
plus  some  associated  programs  and  constraints. 


Specialist: 

Name 

SpecialistsUsed 

BuiltlnConstraints 

DesignPlans 
ReDe sign? Ians 
VerifyPlans 
PlanSuggester 


—  SmallTableOe signer 

—  (TopDesigner 

SupportOesigner) 

—  (STHeight  STTopDiam 
STSupportTopDiamRatio ) 

—  (STPlanl ) 

—  (STRPlanl) 

—  (STVPlanl) 

—  STSuggester 


Plans  The  plan-suggester's  job  is  to  select  the 
appropriate  plans  to  be  followed  during  this 
invocation  of  it's  specialist.  In  general,  the 
plan  selected  could  depend  on  the  requirements 
given  to  the  specialist,  the  request  made  (eg. 
design),  the  history  of  the  design  being  attempted, 
and  the  current  state  of  the  design.  Each 
specialist  vill  have  at  least  one  plan.  Below  we 
present  a  typical  simple  plan  for  the 
SmallTableDesigner .  Note  that  the  steps  marked 
"**"  indicate  places  where  the  system  will  fail  in 
an  unrealistic  manner,  but  a  better  plan  would  be 
too  complex  to  present  here. 


ST  Plan: 

-  use  TopDesigner. 

-  did  it  succeed? 

-  No,  then  plan  FAILS. 

-  use  SupportDesigner . 

-  did  it  succeed? 

-  No,  then  plan  FAILS.  ** 

-  check  to  see  if  design  meets 

table  design  constraints, 
and  the  user's  constraints. 

-  problems? 

-.Yes,  then  plan  FAILS.  ** 

-  if  everything  OK, 

then  table  is  designed, 
and  plan  SUCCEEDS. 


Constraints  Three  constraints  from  the 
TopDesigner  are  given  below.  They  restrict  the 
thickness  of  the  top,  the  material  of  the  top,  and 
the  weight  of  the  top.  Constraints  provide  a 
readable  specification,  explicit  localized  tests  of 
consistency,  and  can  be  used  to  direct  the  flow  of 
control  in  the  hierarchy. 


Constraints : 

TMaterialThickness 
((Thickness  Top)  >  (MinThickness 

(MadeOf  Top))) 


TMaterial 

( (MadeOf  Top)  OneOf  (Values 

(Wood  Marble))) 


TWeight 
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((Area  Top)  *  (Thickness  Top) 
*  (UnitWeight  (MadeOf  Top)) 

<  10) 


Data-bases  Each  specialist  has  access  to 
knowledge  about  parts  and  materials.  For  each 
value  to  be  specified  in  the  design  some  default 
knowledge  is  available.  In  the  implementation  they 
are  functions  giving  either  context-free  or 
context-sensitive  values. 


Part : 

Name  --  Top 


MadeOf  --  Unknown 

Thickness  —  Unknown 

Diameter  —  Unknown 

DefaultThickness  —  DTThickness 
Def aultDiameter  —  DTDiameter 
Def aultMadeOf  —  DTMadeOf 


Material: 

Name  —  Wood 

MinThickness  —  0 .4Q000000E-1 
UnitWeight  —  4 


5.3  Action  of  system 


In  this  section  we  will  present  portions  of  the 
output  produced  by  the  prototype  system,  in  order 
to  show  its  action.  Note  that  the  user's  responses 
appear  after  the  ">>  *"  prompt,  and  that  all  other 
text  is  from  the  design  expert  system.  The  two 
initial  constraints  specify  that  the  table  top  is 
to  be  less  than  2  feet  in  diameter,  and  that  it 
must  be  made  of  Marble.  Having  been  presented  with 
the  design  specification  the  system  can  proceed. 


DESIGN  SYSTEM  PROTOTYPE  (March  83) 
Name  of  most  general 
design  specialist  is? 

»  *SmallTableDesigner 

Any  initial  constraints? 

Answer  y  or  n  or  filename 
»  ^CONSTRAINTS .  IN IT 


Reading  constraints  from  file 
Constraints : 

TopSize  ((Diameter  Top)  <  2) 
MarbleTop  ((MadeOf  Top)  < —  Marble) 

Using  specialist  —  SmallTableDesigner 

In  Mode  — — — — - Design 

From  specialist  -  TOP 

In  plan  — — - - TOP 

Passed  down  - —  (MarbleTop  TopSize) 

Testing  passed-dovn  constraints 
MarbleTop  is  setting  Marble 

as  value  of  MadeOf  in  Top 
Passed-down  constraints  OR 

Testing  built-in  Constraints 
Built-in  constraints  OR 

Suggesting  Plan  STPlanl 
Executing  plan  STPlanl 

Start  by  designing  the  Top 


Before  selecting  its  design  plan  the 
SmallTableDesigner  checked  the  constraints,  and  set 
the  top's  material  to  be  marble.  The  plan  starts 
by  using  the  TopDesigner  to  design  the  top.  Once 
in  control,  the  TopDesigner  checks  the  constraints, 
just  in  case  immediate  failure  can  be  reported,  and 
then  proceeds  to  select  a  plan. 


Using  specialist  —*  TopDesigner 
In  Mode  — — — — —  Design 

From  specialist  -  SmallTableDesigner 

In  plan  -  STPlanl 

Passed  down  — — --  (TopSize  MarbleTop) 

Testing  passed-down  constraints 
Passed-down  constraints  OR 

Testing  built-in  Constraints 
Built-in  constraints  OR 

Suggesting  Plan  TPlanl 
Executing  plan  TPlanl 

Looking  for  unspecified  values  in  Top 
Try  reasonable  values  first 
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AC  this  point  the  plan  for  the  TopDesigner  is 
being  followed,  and,  as  this  is  a  "tip  node"  in  the 
design  hierarchy,  it  must  attempt  to  supply  the 
appropriate  missing  details  of  the  design.  The  plan 
continues,  below,  by  using  "default"  (ie. 
apparently  reasonable)  values  for  those  dimensions 
of  the  top  that  are  not  yet  specified.  After  that, 
the  design  of  the  top  appears  to  be  complete,  so  it 
is  checked  using  the  built-in  and  passed-down 
constraints.  Notice  that  both  of  the  user's 
initial  constraints  are  relevant  for  the 
TopDesigner  and,  consequently,  have  been  passed  to 
it.  Unfortunately  one  of  the  defaults  chosen 
conflicts  with  one  of  the  design  requirements. 
That  default  value  gets  reduced  by  1  inch,  allowing 
all  constraints  to  be  satisfied  ,  and  the  design  to 
continue.  It  could  be  argued  that  the  default 
values  should  have  been  chosen  with  the  constraints 
'in  mind',  but  we  feel  that  the  method  used  fits 
better  into  our  refinement  theory,  as  the  defaults 
provide  a  "rough”  design  which  is  subsequently 
refined  by  consideration  of  the  constraints. 


Selecting  2  ft.  as  Top  diameter 
Selecting  0.2  as  Top  thickness 

Nov  TPlanl  checks  for  conflicts 
Testing  passed-down  constraints 
Constraints  failing 

TopSize:  ((Diameter  Top)  <  2) 

Setting  1.9166669  as 

value  of  Diameter  in  Top 
Passed-down  constraints  OK 

Testing  built-in  constraints 
Built-in  constraints  OK 

No  conflicts  found  by  TPlanl 
Leaving  plan  TPlanl 

Reporting  Success  of  TPlanl  and  TopDesigner 

State  of  design: 

Name  —  Top 

MadeOf  —  Marble 

Thickness  —  0.19999999 

Diameter  —  1.9166669 

DefaultThickness  —  DTThickness 
Def aultDiameter  —  DTDiameter 

DefaultMadeOf  --  DTMadeOf 
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Name  —  Support 

MadeOf  —  Unknown 

Length  —  Unknown 

Diameter  —  Unknown 

DefauLtMadeOf  —  DSMadeOf 

DefaultLength  —  DSLength 

DefaultDiameter  —  DSDiameter 


At  this  point  the  SmallTableDesigner's  plan  calls 
for  the  design  of  the  support,  and  will  pass 
control  to  the  SupportDesigner  specialist,  which 
proceeds  in  much  the  same  way  as  above.  Notice 
that  here  the  default  is  context-sensitive.  Note 
too  that  the  SupportDesigner  uses  the  services  of  a 
module  not  in  the  design  hierarchy  in  order  to  test 
the  strength  of  the  support.  After  the  support  has 
been  designed,  the  SmallTableDesigner  checks  the 
contraints  again,  and,  as  there  are  no  problems, 
the  plan  ia  completed  and  the  design  is  successful. 


Next  design  the  support 

Selecting  Metal  as  Support  material, 
as  Top  material  is  Marble 


Testing  strength 


Reporting  Success  of  STPlanl 
and  SmallTableDesigner 
Result  of  Design  attempt 
(SUCCEEDS) 


.4  Redesign  mode 


Suppose  that,  despite  the  TopDesigner  having 
checked  the  weight  of  the  Top  to  make  sure  that  it 
wasn't  too  heavy,  the  SupportDesigner  is  unable  to 
design  a  support  that  is  strong  enough.  The 
SmallTableDesigner  will  ask  the  TopDesigner  to 
redesign  the  top  given  this  new  information.  In 
cases  such  as  this  we  suspect  that  the  specialist 
involved  will  be  able  to  make  a  judgement  as  to 
whether  this  is  really  a  request  for  a  new  design, 


or  a  minor  change  Co  the  existing  design.  Here, 
the  TopDesigner  would  make  a  decision  whether  to 
select  a  design  plan  other  than  the  one  which  has 
already  been  tried,  or  to  select  a  redesign  plan. 
A  redesign  plan  will  keep  as  much  of  the  old  design 
as  possible  and  will  concentrate  on  changing  only 
whatever  is  necessary  to  correct  the  problem  that 
the  other  specialist  is  having.  Each  specialist 
must  keep  or  have  access  to  a  record  of  which  plans 
have  already  been  tried,  under  what  conditions,  and 
how  successful  they  were. 


6.  AccuRay  Research 


The  design  refinement  ideas  presented  in  the 
previous  sections  are  being  used  in  an  ongoing 
project  to  build  an  expert  system  for  a  more 
complex  and  realistic  class  3  design  task  in  an 
industrial  environment.  In  conjunction  with  AccuRay 
ve  have  studied  the  design  of  a  small  Air-cylinder 
(Figure  3).  The  cylinder  contains  a  piston  on  a  rod 
that  moves  a  shutter  in  one  of  AccuRay's  products. 
Compressed  air  moves  the  piston  to  open  the 
shutter,  and  a  spring  in  the  cylinder,  acting  on 
the  piston  in  the  opposite  direction  to  the  air 
pressure,  closes  it.  The  piston  moves  in  a  sealed 
tube  which  is  closed  at  one  end  by  the  cap,  and  at 
the  other  by  the  head.  The  rod  passes  through  the 
Head.  There  are  about  17  parts  in  all,  some  of 
them  "off-the-shelf",  but  most  are  manufactured  at 
AccuRay  according  to  their  design  specifications. 
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Figure  3  :  Rough  structure  of  Air-cylinder 


After  an  extended  set  of  interviews  with  the 
designer  we  have  captured  the  'trace'  of  the  design 
process  in  some  detail,  and  we  are  still  refining 
it.  The  trace  is  the  design  decisions  and  their 
groupings  considered  over  time.  We  have  also 
isolated  from  this  trace,  in  rough  form,  the 
conceptual  structure  and  the  plans  that  we  consider 
underlie  the  design  refinement  process.  As  the 
implementation  of  the  expert  system  progresses  we 
expect  the  conceptual  structures  and  the  plans  to 
become  better  defined. 


7.  Theoretical  &  Practical  Issues 


of  desian  plans 


&  inter-specialist  communication 


So  far  in  our  descriptions,  plans  are  very 
general  procedures.  However,  in  order  for  this 
notion  to  have  practical  consequences  in  CAD  we 
need  generic  representations  for  plans  and  the 
specification  of  their  coordination.  Otherwise, 
updating  the  expert  system  to  reflect  changing 
products  or  an  increase  in  expertise  will  not  be  a 
practical.  Thus,  we  need  to  search  for  planning 
primitives  with  vhich  a  language  for  design  plans 
can  be  constituted.  The  issue  of  a  plan 
specification  and  refinement  language  is  especially 
important  in  our  framevork  of  problem  solving  types 
and  corresponding  specialist  structures.  We  have 
successfully  completed  the  task  of  specifying  a 
language  called  CSRL  for  the  specification  of 
diagnostic  specialists.  We  expect  that  a  similar 
language  can  be  designed  to  specify  design 
specialists.  We  feel  that  earlier  AI  work  on 
plans,  such  as  that  of  Sacerdoti,  Hayes-Roth  and 
Bruce  ***^»®,  will  be  applicable  to  our  goal. 

In  our  research,  it  is  not  the  time  sequencing  of 
operations  that  is  at  issue,  as  plans  have  already 
been  formed.  We  are  concerned  with  the  notion  of 
constraint  propagation  from  plans  to  subplans, 
either  directly  or  via  some  blackboard  However, 
each  plan  must  show  the  sequence  of  tasks  within 
that  plan,  some  of  vhich  will  use  the  expertise  of 
other  specialists  to  complete  the  task,  and  some  of 
vhich  vill  use  a  "compiled"  ^  procedure  to  complete 
the  task.  Some  specialists  will  be  able  to  proceed 
in  parallel. 


Intimately  bound  up  with  the  language  of  design 
plans  is  the  nature  of  the  communication  between 
specialists.  Most  communication  will  be  between  a 
specialist  and  subspecialists  (ie.  the  ones  at  the 
next  lower  level  of  the  hierarchy,  from  which  it  is 
able  to  request  action).  The  specialists  may  be 
asked  to  design  or  redesign,  and  could  be  asked  to 
validate  some  small  change  that  might  affect  them. 
Each  message  type  will  have  some  information 
associated  with  it.  For  example,  the  message 
requesting  the  redesign  discussed  above  will 
require  some  information  about  the  cause  of  the 
other  specialist's  failure,  and,  possibly,  some 
suggestions  from  that  specialist,  or  a  "boss", 
about  how  to  proceed. 


7.2  How  to  handle  failure 


We  have  only  scratched  the  surface  of  how 
failures  of  refinement  result  in  reinvocation  of 
portions  of  different  plans.  The  issue  is 
significantly  more  complicated.  Sometimes  when  a 
plan  failure  occurs,  it  may  be  more  beneficial  to 
ask  the  parent  specialist  for  some  possibly  minor 
changes  in  specifications  rather  than  invoke 
alternative  plans.  A*  another  example,  consider 
the  case  where  Flan  1  of  a  specialist  S  is  being 
refined,  and  previous  experience  shows  that  a 
potential  conflict  in  a  specialist  S'  several 
levels  below  may  be  a  most  likely  cause  for  failure 
of  the  plan.  Let  us  also  assume  that  several 
successors  of  S  also  have  substantial 
responsibilities  in  the  refinement  of  Plan  1  of  S. 
Now  it  would  seem  prudent  to  selectively  refine  in 
the  direction  of  S'  to  make  sure  early  on  that  Plan 
1  has  a  good  chance  of  survival  rather  than  engage 
all  the  relevant  successors  of  S  immediately. 
Finally,  an  important  problem  is  how  reasons  for 
failure  will  be  used  by  higher  level  specialists  to 
choose  alternate  plans.  Some  degree  of 

"understanding"  the  cause  of  failure  will  be 
necessary.  At  the  very  least  some  sort  of 
classification  of  the  causes  of  failure  into 
categories  that  can  be  mapped  into  criteria  for  the 
selection  of  alternate  plans  will  be  necessary. 

The  above  examples  indicate  that  coordination  of 
plans  may  become  quite  complex.  Further  research 
is  called  for  concerning  the  trade-offs  between 
overly  complex  plans  that  may  capture  some  minor 
detail  of  the  design  process  and  sticking  with 


simpler  plans  Chat  capCure  Che  essence  of  the 
design  process,  but  perhaps  lose  some  efficiency 
due  co  cheir  incompleteness. 


8.  Discussion 


Due  to  space  limitations,  we  have  not  addressed 
several  issues  of  interest,  e.g.,  the  conceptually 
important  but  common  technique  of  "rough  design” 
followed  by  a  more  detailed  design  based  on  some  of 
the  knowledge  gained  during  the  rough  design  phase, 
and  the  practically  important  problem  of  how  to 
incorporate  manufacturability  constraints  in  the 
design  process.  Further  it  is  likely  that  only  a 
subset  of  practical  industrial  Class  3  problems  can 
be  successfully  conquered  by  the  design  refinement 
paradigm.  For  some  design  tasks,  we  may  have  an 
insufficient  understanding  of  the  problem  solving 
processes,  or  have  difficulties  with  the  amount  of 
knowledge  required.  Nevertheless  it  is  our  belief 
that  there  is  a  significant  subset  of  Class  3 
design  problems  Chat  are  amenable  to  the  proposed 
approach.  The  approach  itself  we  think  reflects  in 
a  natural  manner  the  formation  of  conceptual 
structures  for  problem  solving.  Finally,  it  ought 
to  be  pointed  out  that  while  we  have  been  mostly 
discussing  the  prospect  of  "automation”  of  design, 
the  approach  is  also  highly  suited  to 
semi-automation.  An  interactive  system,  in  which 
the  system,  when  faced  with  subtle  issues 
concerning  causes  of  failures  of  some  designs, 
seeks  human  intervention  at  appropriate  points  in 
the  plan  selection  process,  will  obviously  be  very 
useful.  The  knowledge  decomposition  principles 
that  underlie  our  approach  make  the  design  of  such 
semi-automatic  systems  particularly  promising. 
When  knowledge  is  decomposed  into  specialists, 
there  is  no  particular  constraint  regarding  which 
specialists  need  to  be  machine- implemented,  and 
which  can  be  given  to  human  specialists. 
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Aha tract 

We  preaent  CSBL  (Conceptual  Structurea 
Rapreaentation  Language)  aa  a  language  to 
facilitate  the  development  of  expert  diagnoaia 
ayatema  baaed  on  a  paradigm  of  "cooperating 
diagnoatic  apecialiata MDX,  the  medical  diagnoaia 
ayatem  chat  hat  been  developed  in  our  laboratory 
over  the  pact  few  year a  ia  baaed  on  thia  paradigm. 
In  our  approach,  diagnoatic  raaaoning  ia  one  of 
aeveral  generic  caeka,  each  of  which  calla  for  a 
particular  organizational  and  problem  aolving 
rtructure.  A  diagnoatic  etrueture  ia  compoaed  of  a 
collection  of  apecialiata,  each  of  which 
correaponda  to  a  node  or  "concept"  in  a  diagnoatic 
hierarchy,  e.g.,  a  claaaification  of  diaeaaea.  A 
top-down  atrategy  called  eatabliah-refine  ia  uaed 
in  which  either  a  specialist  eatabliahea  and  Chen 
refinea  itaelf,  or  the  apecialiat  rejecta  itaelf, 
pruning  the  hierarchy  that  it  heada.  CSBL  ia  a 
language  for  repreaencing  the  coocepee  of  a 
diagnoatic  hierarchy  and  for  implementing  the 
eatabliah-refine  proccaa.  The  body  of  a  concept 
apecifiea  how  it  will  reepond  to  different  meeaagea 
from  ita  superconcept.  The  knowledge  to  establish 
or  reject  a  concept  ia  factored  into  knowledge 
troupe .  which  correepomd  to  apecific  deciaiona  in 
the  diagnoaia.  We  alao  introduce  the  concept  of  a 
family  of  languagea  ia  which  different  languages 
for  diagnoaia  are  designed  for  different  kinds  of 
end  users . 


I  Introduction 

Many  kinds  of  problem  solving  for  expert  systems 
have  been  proposed  within  the  AI  community. 
Whatever  the  approach,  there  is  a  need  to  acquire 
the  knowledge  in  a  given  domain  and  implement  it  in 
the  apirit  of  the  problem  solving  paradigm. 
Reducing  the  time  to  implement  a  system  usually 
involves  the  creation  of  a  high  level  language 
which  reflects  the  intended  method  of  problem 
aolving.  To  r  example,  EMTCIN  was  created  for 
building  systems  based  on  MTCIN-like  problem 
solving.  Such  languagea  are  also  intended  to  speed 
up  the  knowledge  acquisition  process  by  allowing 
domain  experts  to  input  knowledge  in  a  form  close 
to  their  conceptual  level.  Another  goal  is  to  make 
it  easier  to  enforce  consistency  between  Che 
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expert's  knowledge  and  its  implementation.  In  this 
paper,  we  preaent  CSRL  (Conceptual  Structures 
Representation  Language)  aa  a  language  to 
facilitate  the  development  of  expert  diagnoaia 
ayatema  based  on  the  MDX  approach  to  diagnostic 
problem  aolving  [4,  8],  an  approach  chat  has  been 
developed  in  our  laboratory  over  the  peat  few 
years.  In  addition,  we  introduce  the  concept  of  a 
family  of  languagea  in  which  different  languages 
are  designed  for  different  kinds  of  end  users. 

First,  we  will  overview  the  relationship  of  MDX 
to  our  overall  theory  of  problem  aolving  types,  the 
diagnostic  problem  aolving  that  underlies  MDX,  and 
the  differences  between  our  approach  and  the 
knowledge  base/inference  engine  approach.  We  then 
preaent  CSRL  in  relationship  to  diagnoaia  and 
illustrate  many  of  its  constructs.  Next,  we 
diacuss  the  family  of  languagea  concept.  Finally, 
our  immediate  plana  for  using  CSRL  are  listed.  Due 
to  apace  limitations,  some  understanding  of  how  MDX 
performs  diagnosis  ia  assumed. 


II  Overview  of  MDX 
A.  Types  of  Problem  Solvine 

Our  group  at  Ohio  State  baa  been  concerned  with 
how  knowledge  is  organized  for  expert  problem 
solving.  We  propose  that  there  are  well-defined 
generic  tasks  each  of  which  calls  for  a  particular 
organizational  and  problem  aolving  structure  [3]. 
Some  tasks  that  we  have  identified  are  diagnosis, 
consequence  finding,  and  knowledge-directed  data 
retrieval.  The  knowledge  of  a  given  domain  that 
applies  to  a  given  task  can  be  compiled  into  a 
knowledge  structure  which  is  tuned  for  that  task. 
Thia  structure  is  composed  of  a  collection  of 
apecialiata.  each  of  which  perform  the  same  problem 
solving,  but  specialize  in  different  concepts  of 
the  domain.  Also,  each  task  ia  associated  with  a 
problem  aolving  regime,  i.e.,  how  the  specialists 
coordinate  for  problem  aolving.  The  implementation 
of  MDX  is  based  on  the  diagnostic  task. 


B.  The  Diagnostic  Task 

The  diagnoatic  task  is  the  identification  of  a 
case  description  with  a  specific  node  in 
pre-determined  diagnostic  hierarchy.  The  idea  of  a 
diagnostic  hierarchy  is  well-established  in 
medicine  in  the  form  of  disease  classification. 
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(We  will  uie  medical  terminology  in  Che  following, 
but  the  reader  should  keep  in  mind  that  the 
diagnoetic  taak  alao  applies  to  ocher  domains, 
e.g.,  cars,  computers,  and  power  planes.)  For 
example,  figure  1  shows  that  cholescaais,  eirrosis, 
and  hepatitis  are  subclasses  of  liver  disease. 
Cholestasis  can  be  further  refined  into 
extra-hepatic  and  intra-hepatic  cholestasis.  In 
the  diagnostic  task,  each  disease  is  associated 
with  a  specialist  that  evaluates  its  presence  or 
absence  in  a  patient.  Specialists  in  MDX,  for 
example,  attempt  to  claasify  a  cholestatic  cate 
according  to  its  etiology. 


and  problem  solving  strategy  (escablish-ref ine)  can 
be  used  to  provide  focus  snd  control  in  the  problem 
solving  process. 

Another  difference  is  that  the  specialists  in  the 
hierarchy  are  not  a  static  collection  of  knowledge. 
The  knowledge  of  how  to  establish  or  reject  it 
embedded  within  the  specialists.  Each  specialist 
can  then  be  viewed  as  a  individual  problem  solver 
with  its  own  knowledge  base.  The  entire  collection 
of  specialists  engages  in  distributed 
problem-solving. 


Liver 

_ /  I  \ _ 

/  (  \ 

Cholestasis  Cirrosis  Hepatitis 

/  \ 

/  \ 

Extra-Hep  Intra-Hep 

Figure  1:  Fragment  of  a  diagnoatic  hierarchy 


A  top-down  strategy,  which  we  call 
establish-refine.  is  used  for  this  task.  In 
relation  to  figure  1,  a  simple  version  of  this 
strategy  follows.  First  the  Liver  specialist 
determinea  if  it  is  established,  i.e.,  if  liver 
disease  is  likely.  If  to,  Liver  refines  itself  by 
invoking  its  subspecialists.  Each  succeeding  level 
of  specialists  performs  the  same  establish  and 
refine  functions.  On  the  other  hand,  if  the  Liver 
specialist  rejects  itself,  che  whole  hierarchy  of 
liver  diseases  can  be  pruned.  This  strategy,  in 
combination  with  the  diagnoatic  hierarchy,  it  che 
problem  solving  regime  of  the  diagnostic  task.  For 
a  detailed  analysis  of  diagnostic  problem  solving, 
see  Gomcx  and  Chandrasekaran  [7], 

An  important  companion  to  the  diagnostic 
hierarchy  is  a  data  bate  assistant  which  organises 
the  findings  in  a  relevant  manner  (8,  91.  For 
example,  to  determine  if  a  patient  has  been  exposed 
to  anesthetics,  che  data  baae,  if  necessary,  can 
infer  this  from  other  data,  e.g.,  major  surgery  or 
exposure  to  ether.  Thus  the  diagnostic  structure 
is  insulated  from  solving  problems  about 
finding-finding  relationships,  avoiding  a 
potentially  combinatorial  explosion  of 
finding-disease  relationships  in  the  specialists  of 
the  diagnostic  structure. 


Differences 


The  usual  approach  to  building  knowledge  bated 
systems  it  to  emphasise  a  general  knovledga 
representation  structure  and  different  problem 
solvers  which  use  that  knowledge.  One  difference 
in  the  MDX  approach  is  that  the  organization  of  its 
knowledge  is  not  intended  at  a  genaral 
representation  for  all  problems.  Rather  it  is 
tuned  specifically  for  diagnosis.  By  limiting  the 
type  of  problem  to  be  solved,  a  specific 
organizational  technique  (classification  hierarchy) 


III  CSKL 

CSELL  is  a  language  for  defining  a  diagnostic 
hierarchy  and  for  implementing  the  establish-refine 
process.  A  diagnostic  hierarchy  is  represented  by 
defining  concepts .  Relationships  to  neighboring 
concepts  are  specified  in  the  declarations  of  the 
concept.  Establish-refine  it  implemented  within 
CSRL  via  message  passing.  Each  concept  has  a  body 
which  specifies  how  the  concept  will  respond  to 
different  messages,  and  which  contains  the 
statements  which  invoke  other  concepts  with 
messages.  The  knowledge  to  establish  or  reject  a 
concept  ia  factored  into  knowledge  groups .  which 
determine  how  the  case  description  relates  to 
specific  decisions  in  the  diagnosis.  For  a 
complete  description  of  CSRL,  see  By  lander  [2]. 


and  Messag 


locks  of  a  Concep 


The  body  of  a  concept  contains  s  list  of  message 
blocks,  which  specify  how  the  concept  will  respond 
to  different  messages  from  its  superconcept.  The 
message  block  contains  a  message  pattern,  which  is 
matched  against  tbs  incoming  message,  and  a 
sequence  of  CSRL  statements,  which  are  executed  if 
the  match  succeeda.  In  figure  2,  the  body  of 
Cholestasis  contains  two  message  blocks.  The  first 
one  will  be  activated  if  an  "Establish  Cholestasis" 
message  is  sent  from  its  superconcept,  Liver 
(declared  in  the  Declarations  section),  and  the 
second,  for  a  "Refine  Cholestasis”  message.  The 
literal  "Self”  is  bound  to  the  name  of  the  concept. 


(Def ine-Concept  Cholestasis 

(Declarations  (Subconcept-of  Liver) 

...) 

(Knowledge-Groups  ...) 

(Body 

(Message-Block  (Establish  Self) 

...) 

(Message-Block  (Refine  Self) 

...))) 

Figure  2:  Message  blocks  in  Cholestasis 


Message  blocks  for  establish  messages  are 
relatively  simple  since  the  knowledge  groups 
(described  below)  do  most  of  tbe  work.  Figure  3 
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•  bows  how  one  would  look  for  the  Scone  concept.* 
The  knowledge  group!  ere  named  Xray,  Phyiicel, 
History ,  and  Sunary.  Within  the  (Establish  Self) 
aeasaga  block,  an  Execute  statement  runs  all  the 
knowledge  groupa,  and  than  an  Establish-Reply 
stateaent  asserts  the  value  of  Summary  as  the 
establish  value  of  Stone.  The  establish  value  it 
an  integer  froa  -3  to  3,  which  represents  symbolic 
probabilities  froa  "definitely  not”  to  "definite." 
A  value  of  2  or  3  means  that  the  concept  has  been 
established.  This  value  is  written  on  a  blackboard 
[6],  which  other  concepts  can  access. 


(Def ine-Concept  Stone 

(Declarations  (Subconcept-of  Extra-Hep) 

...) 

(Know  ledge— Groups 
(Xray  ...) 

(History  ...) 

(Physical  ...) 

(Summary  ...)) 

(Body 

(Message-Block  (Establish  Self) 
(Execute  Xray  History 

Phyaical  Summary) 
(Establish-Reply  Summary)))) 

Figure  3:  Statements  for  establishing  Stone 


Refining  a  concept  is  more  complicated  since  the 
message  block  must  be  carefully  tailored  to  follow 
the  establish-refine  strategy.  In  figure  4,  the 
(Refine  Self)  message  block  contains  two  Callexpert 
statements.  The  first  one  calls  each  subconcept 
with  an  establish  message  (S'ubconcepts  is  bound  to 
the  declared  list  of  subconcepts).  The  second 
Callexpert  statement  calls  each  subconcept  that  was 
established  with  a  refine  message. 

Message  passing  is  appropriate  for  the  diagnostic 
task  since  the  establish-refine  regime  easily 
translates  into  a  message  protocol,  in  which  the 
messages  clearly  indicate  the  important  activities 
of  the  concept.  Alao  note  that  although  each 
concept  would  have  an  establish  aeasaga  block  in 
this  formulation,  the  way  that  a  concept 
establishes  itself  is  concept-specific,  i.e.,  a 
concept  has  its  own  knowledge  groups. 


B.  Knowledge  Groups 

The  Knowledge-Groups  section  contains  a  list  of 
knowledge  groups,  which  are  used  to  evaluate  how 
the  case  description  relates  to  the  establish  value 
of  a  concept.  A  knowledge  group  (kg)  can  be 
thought  of  as  a  cluster  of  production  rules  which 
map  the  values  of  a  list  of  conditiona  (boolean  and 
arithmetic  operations  on  data)  to  some  conclusion 
on  a  discrete,  symbolic  scale.  Different  types  of 
kg's  perform  this  mapping  differently,  a.g.. 


*Stone  is  a  subconcept  of  Extra-Hep  in  MDX.  It 
represents  the  disease  "stone  causing  extra-hepatic 
cholestasis." 


(Def ine-Concept  Liver 

(Declarations  (Subconcepts  Cholestasis 

Cirrcsis 

Hepatitis) 

...) 

(Knowledge-Groups  ...) 

(Body 

(Message-Block  (Refine  Self) 

(Callexpert  (E  in  Subconcepts) 
(With-Message  (Establish  E))) 
(Callexpert  (E  in  Subconcepta) 
(With-Message 

(Cond  ((Established?  E) 
(Refine  E)})))) 

...)) 

Figure  4:  Statements  for  refining  Liver 


directly  mapping  values  to  conclusion,  or  having 
each  rule  add  or  subtract  a  set  number  of 
"confidence"  units.  Generally,  the  knowledge  in  a 
concept  is  factored  into  several  kg's,  and  other 
kg's  are  used  to  combine  their  results.  See  IS] 
for  a  discussion  on  combining  diagnostic  knowledge 
in  this  way,  as  well  as  reasoning  with  uncertain 
data. 

Aa  an  example,  figure  5  is  the  Physical  kg  of  the 
Stone  concept  presented  above.  The  conditions 
query  the  data  base  (not  defined  in  CSRL)  for 
whether  the  patient  has  cholangitis,  colicky  pain 
in  the  liver,  or  has  been  vomiting.  Each  rule  in 
the  Match  section  is  evaluated  until  one  "matches.” 
The  value  corresponding  to  this  rule  becomes  the 
value  of  the  kg.  For  example,  the  first  rule  tests 
whether  the  first  and  second  conditions  are  true 
(the  ”?”  means  doesn't  matter).  If  so,  then  3 
becomes  the  value  of  tbe  knowledge  group. 
Otherwise,  other  rules  are  evaluated.  The 
resulting  value  of  tbe  table  measures  the  strength 
of  physical  evidence  towards  establishing  tbe  Stone 
concept.  The  Xray  and  History  kg's  of  Stone 
similarly  evaluate  tbe  radiological  and  historical 
evidence.  The  Summary  kg  combines  their  results 
(the  values  of  the  other  kg's  are  the  conditions  of 
Summary)  into  the  establish  value  of  Stone. 


(Physical 

(Options  (End-After  (Match  1))) 

(Table  (Conditions  (Present?  Cholangitis) 
(Pain?  Abdomen  Colicky) 
(Present?  Vomit)) 

(Match  (If  (T  T  ?)  Then  3) 

(If  (?  T  T)  Then  2) 

(If  (?  T  ?)  Then  1) 

(If  (T  ?  ?)  Then  1) 

(If  (?  ?  ?)  Then  -1)))) 

Figure  3:  Example  of  a  knowledge  group 


Factoring  tbe  knowledge  of  a  concept  in  this 
manner  has  many  advantages.  Only  tbe  relevant 
knowledge  gets  invoked.  It  allows  knowledge  to  be 
acquired  more  easily  from  domain  experts  because 
you  can  focus  their  attention  on  tome  specific 


•ubtask.  It  also  allows  knowledge  to  be  debugged 
because  it  is  easier  to  see  what  purpose  is  being 
served  by  a  knowledge  group.  This  factoring  would 
ask*  it  easier  for  experts  to  directly  enter  the 
knowledge  at  some  future  time. 


Implementation  of  CSBL 


CSE1  is  implemented  on  a  DEC  20/60  using  ELIS?,  a 
dialect  of  LIS?  developed  at  Butgers,  and  a  local 
version  of  FRL  (Frame  Representation  Language). 
The  CSBL  interpreter  and  enviroment  takes  up  an 
additional  33K  vorda  of  storage.  The  environment 
includes  a  thorough  syntax  check  when  concepts  are 
defined,  commands  to  invoke  any  concept  with  any 
message,  and  a  simple  trace  facility.  CSBL 
currently  allows  little  user  interaction  while  it 
is  running,  but  in  the  future  we  plan  to  add  a 
simple  explanation  facility  and  to  allow  the  user 
to  "advise”  the  system  during  execution. 


T  Current  Flans 

Our  group  at  Ohio  State  is  currently  using  CSBL 
in  a  variety  of  domains  including  blood  type 
analysis,  cars,  and  nuclear  power  plants.  We  are 
also  translating  MDX's  diagnostic  structure  from 
the  present  LIS?  code  to  CSBL.  We  also  plan  to 
implement  a  diagnosis  language  which 
non-programmers  can  use  with  minimal  training  to 
implement  prototype  diagnostic  systems. 
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IT  Family  of  Languages 

Designing  languages  for  knowledge  representation 
often  has  to  face  conflicting  requiraents .  At  one 
end,  they  should  be  powerful  enough  to  allow 
different  kinds  of  knowledge  and  control  to  be 
expressed.  The  power  is  needed  in  the  form  of 
flexibility  in  the  programming  constructs 
available.  At  the  other  end,  the  language  should 
be  simple  enough  so  that  non-programmers  such  as 
domain  experts  can  directly  encode  their  knowledge 
without  having  to  worry  about  the  representation  in 
the  machine. 
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definitely  restricted  to  be  top-down. 
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Auto-Mech  is  an  expert  system  which  diagnoses  automobile  fuel  systems.  Its 
organization  and  strategies  are  patterned  after  MDX,  an  expert  diagnosis 
system  developed,  in  our  AI  laboratory.  The  problems  that  these  systems  are 
able  to  diagnose  are  represented  as  nodes  within  a  hierarchy.  Each  node  has 
knowledge  about  how  to  confirm  or  reject  the  problem  hypothesis,  as  well  as 
knowledge  about  what  nodes  to  consider  next.  This  approach  is  intended  to  be 
a  domain-independent  methodology  for  providing  focused  problem  solving  and  for 
localizing  knowledge  in  a  conceptually  relevant  manner.  Auto-Mech  is 
implemented  in  a  recently  developed  language  called  CSBL,  which  is 
specifically  intended  for  building  diagnostic  expert  systems.  This  paper 
describes  Auto-Mech  and  discusses  why  the  MDX  approach  and  CSBL  were  useful  in 
developing  Auto-Mech,  and  where  some  difficulties  were  encountered. 

1.  Introduction 

Over  the  past  few  years,  our  AI  laboratory  has  developed  an  approach  to  the 
design  of  expert  diagnosis  systems  based  on  the  paradigm  of  "cooperating 
specialists ."  This  approach  is  exemplified  in  an  expert  system  called 
MDX  [3,  61,  whose  expertise  is  in  cholestatic  liver  disease.  In  order  to 
demonstrate  the  viability  of  this  approach  to  non-medical  domains,  we  have 
developed  a  system  called  Auto-Mech  which  diagnoses  problems  in  automobile 
fuel  systems.  We  show  that  an  organization  of  diagnostic  knowledge  which  is 
similar  to  MDX  can  be  used  in  this  domain  to  provide  focused  problem  solving, 
and  to  localize  knowledge  in  a  conceptually  relevant  manner. 

Auto-Mech  is  implemented  in  a  recently  developed  language  called  CSBL  [2], 
which  was  designed  specifically  for  building  MDX-like  diagnostic  expert 
systems.  Thus  another  goal  of  this  work  was  to  determine  the  strengths  and 
weaknesses  of  CSBL  and  to  make  recommendations  for  future  versions  of  CSBL. 

Briefly,  Auto-Mech  works  as  follows.  When  Auto-Mech  begins  diagnosis  i  it 
obtains  a  specific  complaint  about  the  way  the  car  operates.  Then  general 
hypotheses  about  the  nature  of  the  problem  are  evaluated.  When  a  hypothesis 
is  confirmed,  any  hypotheses  which  are  immediately  more  specific  are 
considered.  The  user  is  queried  for  additional  information  as  needed  during 
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this  process.  Auto-Mech  ,  is  not  intended  to  be  a  complete  model  of  an 
automobile  mechanic,  but  is  intended  to  reflect  the  information  processing 
capability  of  a  mechanic  when  she  attempts  to  determine  the  specific  cause  of 
a  fuel  problem  from  an  initial  complaint  and  from  things  that  a  typical 
mechanic  can  observe  when  she  looks  under  the  hood. 

Before  we  present  a  more  detailed  description  of  Auto-Mech,  we  give  an 
overview  of  our  approach  to  diagnostic  problem  solving-  We  then  describe  the 
program,,  explaining  Che  assumption*  that  we  have  made,  and  outlining  its 
organization.  An  annotated,  session  of  Auto-Mech  and  a  sample  of  its  CSRL  code 
is  included..  Finally,  we  discuss  why  our  approach  and  CSRL  were  useful  in 
developing  Auto-Mech,  and  where  some  difficulties  were  encountered. 

2.  Introduction  to  Diagnostic  Problem  Solving 

The  central  problem  solving  of  diagnosis,  in  our  view,  is  classif icatory 
activity.  This  is  a  specific  type  of  problem  solving  in  our  approach,  meaning 
that  a  special  kind  of  organization  and  special  strategies  are  strongly 
associated  with  performing  expert  diagnosis.  We  will  not  examine  here  how 
classificatory  diagnosis  fits  in  with  our  overall  theory  of  problem  solving 
(see  Chandrasekaran  [4]).  Instead,  ve  will  briefly  overview  the  structure  and 
the  strategies  of  classificatory  diagnosis.  For  the  purposes  of  this 
discussion,  we  will  use  "diagnosis"  in  place  of  "classificatory  diagnosis" 
with  the  understanding  that  the  complete  diagnostic  process  includes  other 
elements  as  well. 

The  diagnostic  task  is  the  identification  of  a  case  description  with  a 
specific  node  in  a  prs-determined  diagnostic  hierarchy.  Each  node  in  the 
hierarchy  corresponds  to  a  hypothesis  about  the  state  of  the  "patient”  (a  car 
in  the  Auto-Mech  program) .  Nodes  higher  in  the  hierarchy  represent  more 
general  hypothesis,  while  lower  nodes  are  more  specific.  In  medicine,  a  case 
description  is  the  manifestations  and  the  history  of  a  patient,  and  a 
diagnostic  hierarchy  is  a  classification  of  diseases  and  disease  classes.  For 
example,  MDZ  [3,  6]  attempts  to  classify  a  medical  case  into  a  diagnostic 
hierarchy  of  cholestatic  diseases.  Figure  1  illustrates  a  fragment  of  MDX's 
hierarchy.  The  most  general  disease,  cholestasis  in  this  example,  is  the  head 


node  of  Che  hierarchy.  More  specific  cholestatic  diseases  such  as  extra** 
hepatic  cholestasis  are  classified  within  the  hierarchy.  In  the  following 
discuasion,  we  will  use  the  generic  term  "problem"  rather  than  "disease". 


Cholestasis 

_ /  \ _ 

/  \ 

Extra-hepatic  Intra-hepatic 

Cholestasis  Cholestasis 

/  \ 

/  \ 

EEC  Due  to  EEC  Due  to 

Bile  Duct  Stone  Bile  Duct  Tumor 

Figure  1:  Fragment  of  MDX's  diagnostic  hierarchy 

Each  problem  in  the  hierarchy  is  associated  with  a  specialist  which 
contains  the  diagnostic  knowledge  to  evaluate  the  presence  or  absence  of  the 
problem  from  the  case  description.  From  this  knowledge,  the  specialist 
determines  a  confidence  value  representing  the  amount  of  belief  that  the 
problem  exists.  If  this  value  is  high  enough,  the  specialist  is  said  to  be 
established.  Note  that  each  specialist  is  a  problem  solver  with  its  own 
knowledge  base. 

The  basic  strategy  of  the  diagnostic  task  is  a  process  of  hypothesis 
refinement,  which  we  call  establish-refine.  In  this  strategy,  if  a  specialist 
establishes  itself*  then  it  refines  the  problem  hypothesis  by  invoking  its 
subspecialists,  which  also  perform  the  establish-refine  strategy.  If  the 
confidence  value  is  low,  the  specialist  rejects  the  problem  hypothesis,  and 
performs  no  further  actions.  Note  that  when  this  happens,  the  whole  hierarchy 
below  the  specialist  is  eliminated  from  consideration.  Otherwise  the 
specialist  suspends  itself,  and  may  later  refine  itself  if  its  superior 
requests  it.  The  processing  ends  (if  we  assume  that  only  one  problem  is- 
present)  when  a  tip  node  specialist,  a  specialist  with  no  subspecialists,  has 
been  established. 

With  regard  to  Figure  1,  the  following  scenario  might  occur.  First,  the 
cholestasis  specialist  is  invoked,  since  it.  is  the  top  specialist  in  the 
hierarchy.  Cholestasis  is  then  established,  and  the  two  specialists  belov  it 
are  invoked.  Extra-hepatic  cholestasis  is  rejected,  also  eliminating  SC  due 
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Co  scone  and  bile  ducC  cancer  from  furCher  consideration.  Finally,  intra- 
hepacic  cholescasis  establishes  itself,  and  invokes  its  subspecialists. 

Due  Co  space  and  cine  limitations,  ve  have  not  addressed  several  issues 
relevant  Co  diagnostic  problem  solving  (such  as  handling  multiple  problesis). 
For  a.  more  detailed,  analysis,  see  Gomez  and  Chandra sekar an  [5].  Test 
ordering,  causal  explanation  of  findings,  and  therapeutic  action  do  not 
directly  fall  within  the  auspices  of  classificatory  diagnosis,  but  expertise 
in  any  of  these  areas  would  certainly  enhance  a.  diagnostic  system.  Fully 
resolving  these  issues  and  integrating  their  solutions  into  the  diagnostic 
framework  are  problems  for  future  research. 

3.  The  Automobile  Diagnosis  Program. 

3.1.  Description  of  Auto-Mech 

Auto-Mech  is  a  program  which  diagnoses  fuel  problems  in  automobile  engines. 
It  was  developed  using  CSRL  (which  will  be  described  in  Section  3.3)  and  the 
eatablish-refine  problem-solving  methodology  described  in  Section  2. 

One  reason  the  domain  of  automobile  diagnosis  was  chosen  is  that  most 
people  feel  comfortable  discussing  car  problems  thus  making  such  a  program 
easy  to  demonstrate.  We  also  had  two  good  amateur  mechanics  available  to 
serve  as  experts.  We  decided  to  concentrate  on  fuel  problems  because  the  fuel 
system  is  sufficiently  complex  to  be  interesting  and  simple  enough  to  do  in  a 
short  time. 

Before  discussing  the  program  further  a  brief  discussion  of  automobile  fuel 
systems  is  in  order.  The  purpose  of  the  fuel  system  is  to  deliver  a  mixture 
of  fuel  and  air  to  the  cylinders  of  the  engine.  It  can  be  divided  into  four 
major  subsystems: 

1.  the  fuel  delivery  subsystem  which  brings  fuel  from  the  tank  to  the 
carburetor, 

2.  the  air  intake  which  brings  air  into  the  carburetor, 


3.  the  carburetor  which  mixes  the  air  and  fuel  in  the  proper  ratio, 
and 


4.  the  vacuum  manifold  which  brings  the  mixture  to  the  cylinders . 


These  subsystems  correspond  to  initial  hypotheses  about  fuel  system  faults  and 
each  can  be  further  refined  by  more  detailed  descriptions. 

Just  as  hospitals  have  a  routine  series  of  data  to  collect  about  every 
patient  admitted.,.  Auto-Mach  collects  a  set  of  initial  data  to  get  the 
diagnosis  running.  We  refer  to  the  initial  data  as  defining  the  user's 
complaint.  The  complaint  is  a  problem-condition  pair  where  the  problem  is  the 
symptom,  the  user  notices  (such  as  stalling  or  running  rough)  and  the 
conditions  include  the  kind  of  driving  in  which  the  problem  occurs 
(accelerating,  idling,  etc.)  and  the  approximate  engine  temperature  (hot, 
cold.,  or  both).  Hote  that  the  complaint  is  highly  symptomatic. 

We  chose  to  implement  a  program  around,  a  generic  automobile  fuel  system 
rather  than  the  fuel  system  of  a  particular  car.  Reasoning  about  the  fuel 
system  depends  on  its  design,  which  can  vary  in  many  ways.  Within  the  CSRL 
framework  each  design,  requires  its  own  diagnostic  hierarchy  so  we  had  to  make 
a  few  assumptions  about  the  system.  The  major  assumptions  are: 

-  carbureted  engine 

-  single  barrel,  single  stage,  downdraft  carburetor 

-  mechanical  fuel  pump 

-  automatic  transmission 

-  non-computer  ignition 

-  automatic  choke 

-  minimal  pollution  control  systems 

Each  of  these  assumptions  has  diagnostic  consequences.  A  carbureted  engine, 
for  example,  will  have  a  different  set  of  problems  than  a  fuel  injected  engine 
(the  former  can  have  a  broken  carburetor).  Many  of  these  assumptions  would  be 
valid  for  most  cars  built  before  1980  or  so.  Those  that  are  not  would  either 
add  complexity  without  making  the  problem  more  interesting  (such  as  a  two- 
stage  carburetor)  or  vary  so  widely  that  no  single  generic  arrangement  can  be 
imagined  (such  as  pollution  controls). 


We  also  made  a  few  simplifying  assumptions  about  the  problem  solving 
required  of  the  program.  The  most  important  of  these  is  our  single  complaint 
assumption. *  This  means  that  for  any  session  with  the  program  the  user  can 
specify  only  one  major  complaint  (a  problem-condition  pair  as  described 
above).  One  difficulty  with  multiple  complaints  is  the  need  to  keep  the 
problem-condition  pairs  together.  If  the  complaints  were  "stalls  while 
idling”'  and  "hesitates  on  acceleration"  it  would  be  necessary  to  know 
"stalls”,  "hesitates",  "idling",  "acceleration",  and  that  the  complaints  are 
not  "stalls  on  acceleration"  and.  "hesitates  while  idling".  The  simple  data 
base  provided  with  CSBL  does  not  provide  for  this  kind  of  reasoning.  This 
could  be  rectified  by  implementing  a  special  data  base.  Another  difficulty 
with  allowing  many  complaints  is  keeping  the  line  of  questioning  focused  on 
one  complaint.  Given  many  complaints,  large  portions  of  the  hierarchy  will  be 
relevant  and  the  questioning  may  appear  random  to  a  user  unless  some  mechanism 
is  used  for  focusing  the  questioning.  Such  a  mechanism  was  not  readily 
available.  Solving  these  problems  would  have  either  added  to  the  time  taken 
for  the  project  as  a  whole  or  subtracted  from  the  time  devoted  to  the  main 
purpose  of  developing  Auto-Mech  —  to  teat  CSBL  and  eatablish-ref ine  problem¬ 
solving.  So  we  chose  to  restrict  the  problem-solving  to  a  single  complaint  at 
a  time. 

Another  simplifying  assumption  we  made  is  that  the  data  to  be  used  by  the 
system  be  from  commonly  available  sources.  Mechanics  now  have  an  array  of 
computer  analysis  information  available  which  our  experts  were  unfamiliar 
with.  So  we  limited  ourselves  to  such  data  as  whether  a  component  is  working 
and  how  the  car  behaves  in  certain  situations. 

Figure  2  shows  part  of  the  diagnostic  hierarchy  for  Auto-Mech.  Each  node 
in  the  hierarchy  is  a  specialist  representing  a  hypothesis  together  with 
knowledge  about  how  to  confirm  or  reject  the  hypothesis.  For  example,  the 
specialist  named  Delivery  represents  the  hypothesis  "Fuel  delivery  subsystem 
is  causing  the  problem."  Delivery  also  contains  knowledge  about  the  types  of 


This  is  most  emphatically  not  a  single  fault  assumption.  If  there  is  more 
than  one  fault  causing  the  complaint,  Auto-Mech  can  find  it. 
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Figure  1:  Partial  Diagnostic  Hierarchy  for  Auto-Mech 


complaints  for  which  fuel  delivery  problems  should  be  considered  and  how  to 
infer  that  fuel  is  not  being  delivered  to  the  carburetor.  The  purpose  of  the 
top— level  specialist,  Engine,  is  to  collect  the  initial  complaint  information 
and  begin  diagnosis.  The  ellipsis  in  the  diagram  represent  points  where  the 
hierarchy  continues  down. 


3.2.  Annotated_Transcript  of  a  Session  with  Auto-Mech 

In  the  following  transcript  of  a.  session  with  Auto-Mech  the  user's 
responses  follow  the  ">N  prompt,  comments  are  underlined,  and  everything  else 
comes  from  the  program. 

The  user  first  tells  the  top  level  specialist.  n».  to 
establish  and  then  refine  itself.  The  program  then  prints  a 
brief  statement  of  the  diagnostic  system's  scope  and  begins 
collecting  information  about  the  problem. 

>DoCSRL  Engine  Establish-Ref ine 

This  is  a  program  to  diagnose  automobile  problems.  At  the  present 
time  the  the  program  only  knows  about  fuel  problems.  The  first  series 
of  questions  is  an  attempt  to  determine  what  the  problem  is  (starting 
problem,  rough  running,  stalling,  hesitation,  slow  response, 
knocking),  and  the  conditions  under  which  it  occurs  (idling,  loading, 
accelerating,  cruising,  turning,  decelerating,  engine  temperature). 

After  this  the  rest  of  the  questions  are  attempts  to  confirm  or  reject 
hypotheses . 

Do  yon  have  problems  starting  your  car?>? 


Answers: 

I  -  Yes 

N  •  No 


U  •  Unknown 


If  the  user  doean^t  know  how  to  respond.  "?"  will  provide  a, 
description  of  acceptable  answers .  All  of  the  questions  in 
this  program  are  answered  "ves".  "no " .  or  "unknown"  for 
simplicity.  CSRL  does  provide  facilities  for  using  any 
answers  which  are  appropriate  including  such  things  as 
numerical  values  and  multiple  choice. 

Do  70a  have  problems  starting  your  car?>N 

Does  the  ear  stall?>H 

Does  the  car  run  rough? >Y 

Does  the  problem  occur  while  idling?>H 

Does  the  problem  occur  on  loading?>7 

Does  the  problem  occur  while  the  engine  is  both  hot  and  cold?>Y 

the  problem  the  user  has  specified  is  "the  engine  runs  rough" 
and  the  conditions  are  "on  loading  and  independent  of  engine 
temperature".  The  only  purpose  of  the  Engine  specialist  is  to 
determine  the  complaint.  Certain,  terms  require  specific 
definitions  in  order  to  clearly  separate  some  problems  and 
conditions .  For  loading  means  putting  some  strain  on 

thm  engine  wifchaufc  seeeleratiny-  idling  means  the  engine  is 

running  bat  there  is  no  load  on  it. 

»>  Message  Trace  «< 

From 7  EHGIHE  To:  FUEL 
Message:  ((ESTABLISH  FUEL)) 

Engine  now  refines  by  first  telling  its  subspecialist.  Fuel. 
SSL 

Have  you  eliminated  ignition  as  a  possible  cause  of  the  problem?>T 

This  question  shows  the  need  to  know  what  other  specialists 
have  done.  Auto  experts  have  determined  that  many  problems 
which  might  be  fuel  nrnhiwna  are  more  likely  to  be  ignition 
nrfthi  — .  This  user's  auto  complaint  is  one  of  those  cases  so 
Fuel  wants  to  make  sure  Ignition  has  reiected  itself. 

However.  Ignition  has  not  been  implemented  eg.  the  user  is. 
asked  if  the  ignition  system  has  been  considered  and  reiected. 


>»  Massage  Trace  «< 

From:  FUEL  To:  EHGIHE 
Message:  ((ESTABLISHED  FUEL  2)) 


»>  Message  Trace  «< 
From:  ENGINE  To:  FUEL 
Message:  ((REFINE  FUEL)) 


Once  its  subspecialist.  Fuel,  establishes.  Engine  continues 
refine  by  telling  Fuel  to  refine  itself.  The  next  series  of 
messages  and  questions  shov  the  nyn<rram  considering  Delivery. 
Mjggffla*  Vacuum.  Air- Intake,  and  Bad-Gas  as  hypotheses  about 
the  cause  of  the  problem.  The  data  base  provided  with  CSRL 
records  each  question  asked  and  the  user^s  answers  to  avoid 
asking  them  again*  So  the  decisions  the  specialists  make  are 
not  based  entirely  on  the  answers  to  questions  shown  under 
each  specialist,  but  on  combinations  of  the  answers  to  those 
and  previous  answers . 


>»  Message  Trace  «< 

From:  FUEL  To:  DELIVERY 
Message:  ((ESTABLISH  DELIVERY)) 

I*  any  fuel  delivered  to  the  earbnretor?>U 

»>  Message  Trace  «< 

From:  DELIVERY  To:  FUEL 
Messagmr  ((REJECTED  DELIVERY  -2)) 

»>  Message  Trace  «< 

From:  FUEL  To:  MIXTURE 
Message:  ((ESTABLISH  MIXTURE)) 

Have  yoa  been,  getting  bad  gas  mileage ?>N 

»>  Message  Trace  <« 

From:  MIXTURE  To:  FUEL 
Message:  ((REJECTED  MIXTURE  -3)) 

»>  Message  Trace  <« 

From:  FUEL  To:  VACUUM 
Message:  ((ESTABLISH  VACUUM)) 

»>  Message  Trace  «< 

From:  VACUUM  To:  FUEL 

Message:  ((ESTABLISHED  VACUUM  3)) 

»>  Message  Trace  «< 

From;  FUEL  To:  AIR- INTAKE 
Message:  ((ESTABLISH  AIR-INTAKE)) 

Is  the  air  filter  old?>N 

»>  Message  Trace  «< 

From:  AIR-INTAKE  To:  FUEL 
Message:  ((REJECTED  AIR-INTAKE  -2)) 


>»  Message  Trace  «< 

From:  FUEL  To:  BAD-GAS 
Message:  ((ESTABLISH  BAD-GAS)) 

Have  70a  Cried  a  higher  grade  of  gas?>7 

»>  Message  Trace  <« 

From:  BAD-GAS  To:  FUEL 
Message:  ((REJECTED  BAD-GAS  -3)) 

>»  Message  Trace  <« 

From:  FUEL  To:  VACUUM 
Message:  ((REFINE  VACUUM)) 

Fuel  now  asks  its  established  subspecialists  to  refine.  In 
this  case  only  Vacnna  has  established. 

»>  Message  Trace  «< 

From:  VACUUM  To:  VACUUM-HOSES 
Message:  ((ESTABLISH  VACUUM-HOSES)) 

Are  there  any  cracked,  punctured  or  loose  vacuum  hoses?>U 

This  question  strange  because  it  appears  to  be 

equivalent  to  asking  rhether  the  hypothesis  should  be 
confirmed.  But  vhen  Auto-Mach  gets  to  a  very  specific 
hypothesis  uauallr  the  only;  data  for  confirming  or  misting 
it  comes  from  direct  observation  of  a  pert. 

Can  70a  hear  hissing  while  the  engine  is  running?>N 

Are  the  vacuum  hoses  old? >7 

»>  Message  Trace  «< 

From:  VACUUM-HOSES  To:  VACUUM 
Massage:  ((UNKNOWN  VACUUM-HOSES  1)) 

The  information  that  Vacuum-Hoses  has  is  not  certain,  some 
indicates  trouble  and  seme  doesn't.  So  the  answer  is 

but  the  value  "l"  indicates  that  it  leans  toward 

1  •  - L  J  _ 


»>  Message  Trace  «< 

From:  VACUUM  To:  CARBURETOR-GASKET 
Message:  ((ESTABLISH  CARBURETOR-GASKET)) 

Can  you  see  cracks  in  the  carburetor  gasket?>7 

»>  Message  Trace  «< 

From:  CARBURETOR-GASKET  To:  VACUUM 
Message:  ((ESTABLISHED  CARBURETOR-GASKET  3)) 


Is  Che  diagnosis  of  VACUUM  finished?>Y 


CS8L  and  Auto-Mech  are  unable  to  determine  when  diagnosis  is 
finished .  The  mechanism  we  use  asks  the  user  as  control 
passes  up  through  the  hierarchy  from  the  lowest  point  reached . 
If  the  user  answers  "Yes'*,  as  in  this  case,  then  control 
passes  on  up  the  hierarchy.  Another  of  the  user"s  options 
here  is  to  answer  "No1*.  In  that  case  CSRL  would  refine  those 
subspecialists  of  Vacutm  which  were  "unknown1*,  such  as  Vacuum- 
Hoses  .  Unless  the  pmcrram  ja  told  to  do  this  only 
"established"  subspecialists  will  get  refined.  In  this 
particular  case  the  question  indicates  a  bug  in  the  Auto-Mech 
program. itself  since  Vacuum" a  subspecialists  are  all  tip 
specialists. 


>»  Message  Trace  «< 

From:  VACUUM  To:  FUEL 

Message:  ((ESTABLISHED  CARBURETOR-GASKET  3)  (UNKNOWN  VACUUM-HOSES  1)) 

Is  the  diagnosis  of  FUEL  finished?>Tree 

FUEL  111 1  2 

DELIVERY  —  -2 

MIXTURE - 3 

VACUUM  —  3 

VACUUM-HOSES  —  1 
CARBURETOR-GASKET  —  3 
AIR-INTAKE  —  -2 
BAD-GAS  - 3 


The  user  also  has  the  option  of  printing  out  the  diagnostic 
hierarchy  with  the  values  displayed  for  each  specialist . 


Is  the  diagnosis  of  FUEL  finished?>Y 


»>  Message  Trace  «< 

From:  FUEL  To:  ENGINE 

Massage:  ((UNKNOWN  VACUUM-HOSES  1)  (ESTABLISHED  CARBURETOR-GASKET  3) 
(REJECTED  BAD-GAS  -3)  (REJECTED  AIR- INTAKE  -2)  (ESTABLISHED  VACUUM  3) 
(REJECTED  MIXTURE  -3)  (REJECTED  DELIVERY  -2)) 

Is  the  diagnosis  of  ENGINE  finished?>Y 

(ANSWER  (REJECTED  DELIVERY  -2) 

(REJECTED  MIXTURE  -3) 


(ESTABLISHED  VACUUM  3) 

(REJECTED  AIR- INTAKE  -2) 

(REJECTED  BAD -CAS  -3) 

(ESTABLISHED  CARBURETOR-GASKET  3) 
(UNKNOWN  VACUUM-HOSES  1) 
(ESTABLISHED  FUEL  2) 

(ESTABLISHED  ENGINE  3)) 


The  answer  is  simply  a,  list  of  the  specialists  which  ran  and 
their  values  .  The  diagnosis  is  the  established  tip 
Carburet 


Figure  3  shows  the  CSRL  code  for  implementing  the  Bad-Gas  specialist  vhich 
considers  the  hypothesis  "Something  wrong  with  the  fuel  is  causing  the 
problem."  The  specialist  is  defined  by  the  Define-Concept  statement.  Like 
all  CSRL  specialists  it  is  made  of  three  parts: 

-  Declarations,  containing  information  about  where  the  specialist  fits 
in  the  hierarchy. 

-  Knowledge-Groups,  showing  the  major  categories  of  decisions  to  be 


-  Body,  which  controls  the  way  in  which  the  specialist  responds  to 
various  messages . 

The  boldface  represents  built-in  CSRL  primitives,  everything  else  is 
determined  by  the  system  builder.  And-YNU  is  a  three-valued  logical  AND  which 
is  defined  for  T,  N,  ami  U.  Use-Declaration  and  Use-Statement  invoke  CSRL 
macro-instructions  that  expand  into  longer  sequences  of  statements  which  do 
not  vary  from  specialist  to  specialist.  The  Use-Declaration's  h«re  set  up 
standard  variables  and  constants  for  the  CSRL  interpreter  to  use.  The  Use- 
Statement's  implement  the  establish-ref ine  problem-solving  process.  Since  the 
interesting  thing  is  how  Bad-Gas  establishes  or  rejects  itself,  we  will  not 
discuss  these  other  processes  here. 

The  general  description  of  how  Bad-Gas  reasons  is : 

First  make  sure  BadHaas  is  a  relevant  hypothesis  to  hold.  If  it  is 
not  then  reject.  If  it  is  relevant  find  out  if  there  is  any  reason  to 
believe  something  has  happened  to  the  fuel  recently.  If  there  is  none 
then  reject.  But  if  there  is  some  reason  to  believe  this  then 
establish  with  value  depending  on  how  relevant  the  hypothesis  is. 


(Define-Concept  Bad-Gas 

(Declarations  (Subconcept-Of  Fuel) 

(Subconcepts  Lov-Octane 

Water-In-Fuel 
Dirt- In-Fuel) 

(Dee-Declaration  Usual-Variables) 

(Use-Declaration.  Usual-Constants)) 

(Knowledge-Groups 

(Relevant 

(Options  (End-After  (Hatch  1))) 

(liable  (Conditions 

(Aek-YSU?  "Is  the  car  slow  to  respond") 

(Ask-mU?  "Does  the  car  start  hard") 

(And-YHU 

(Ask-YNU?  "Do  you  hear  knocking  or  pinging  sounds”) 
(Ask-YHU?  "Does  the  problem  occur  while  accelerating"))) 
(Match  (If  (  Y  ?  ?  )  Then  -3) 

(If  (  ?  Y  ?  )  Then  -3) 

(If  (  ?  ?  Y  )  Then  3) 

(If  (  ?  ?  ?  )  Then  1)))) 

(Gas 

(Options  (End-After  (Match  1))) 

(Table  (Conditions 

(Ask-YlIU?  "Have  you  tried  a  higher  grade  of  gas") 
(Aak-YHU?  "Did  the  problem  start  after  the  last  fillup”) 
(Ask-YHU?  "Has  the  problem  gotten  vorse  since  the  last 
fillup")) 

(Match  (If  (  Y  ?  ?  )  Then  -3) 

(If  (  ?  Y  ?  )  Then  3) 

(If  (  ?  M  Y  )  Then  2) 

(If  (  ?  ?  ?  )  Then  -3)))) 

(Suamary 

(Options  (End-After  (Match  1))) 

(Table  (Conditions  Relevant  Gas) 

(Match  (If  (  3  (Ge  0)  )  Then  3) 

(If  (  1  (Ge  0)  )  Then  2) 

(If  (  ?  (Lt  0)  )  Then  -3))))) 

(Body 

(User-Statement  Usua  1-Es  tab  1  is  hr  Refine) 

(Message-Block  (Establish  Self) 

(Execute  Relevant) 

(Case  Relevant 

((Ge  0) (Execute  Gas  Summary) 

'  ( Ss tab lis hr Reply  Susnary)) 

(Otherwise  (EstablishrReply  Relevant)))) 

(Use-Statement  Simple-Refine) 

(Use-Statement  Pass-Messages))) 


Figure  3:  CSRL  code  for  a  specialist 


To  implement  this  Bad-Gas  has  a  group  of  statements  in  the  Body  which  begin 

(Message-Block  (Establish  Self)  ...  ) 

and  which  will  be  activated  when  a  message  to  establish  is  received  from  the 
Fuel  specialist**  The  Message-Block  controls  the  order  in  which  the 
Knowledge-Groups  (Relevant,  Gas,  and  Summary)  are  evaluated.  Summary  combines 
the  results  of  Relevant  and  Gas.  The 

(Execute  Relevant) 

statement  causes  the  Relevant  knowledge-group  to  run.  If  Relevant  returns  a 
non-negative  value  the  Gas  and  Summary  groups  run  with  the  establish-value  of 
Bad-Gas  set  by  Summary.  If  Relevant  returns  a  negative  value  the  establish- 
value  of  Bad-Gas  is  set  by  Relevant  and  the  other  two  groups  are  not  run. 
This  choice  is  implemented  by  the  construct: 

(Cass  Relevant 
C(Ge  0)  ...  ) 

(Otherwise  ...  )) 

Very  detailed  descriptions  of  how  all  of  the  knowledge  groups  work  is  not 
necessary.  In  general,,  running  a  knowledge-group  consists  of  testing  its 
Conditions  and  trying  to  match  their  results  to  one  of  the  rows  in  the  Match 
table.  A.  condition  which  begins  with  Ask-YHUT  causes  CSRL  to  look  in  its 
string-value  data  base  for  the  given  string.  If  found  then  the  value  stored 
there  becomes  the  value  of  the  condition.  If  not  found,  the  string  is 
displayed  as  a  question  to  the  user.  The  user's  response  is  stored  in  the 
string-value  data  base  and  is  used  as  the  value  of  the  condition.  If  the 
condition  is  the  name  of  a  knowledge-group  its  value  is  the  value  of  the 
knowledge-group.  The  rows  (or  "rules")  of  the  Match  table  are  tried  one  at  a 
time,  from  the  top  down.  As  soon  as  a  row  is  found  which  matches  the  value  of 
the  conditions,  the  Then-part  gives  the  value  of  the  knowledge-group  and  the 
evaluation  of  the  knowledge-group  stops.  The  "?"  in  the  tables  is  a  wild- 

*CSRL  can  be  viewed  as  a  restricted  object  oriented  language  in  which  thie 
objects  are  the  specialists  and  the  messages  are  instructions  to  the 
specialists . 


card,  ic  matches  any  value 


In  the  transcript  given  earlier  the  value  of  the  conditions  in  the  Relevant 
knowledge-group  are  (N  N  N)  so  the  row 

If  (?  ?  ?)  Then  1 

matches  and  the  value  of  Relevant  is  1 .  This  is  a  result  of  the  previously 
supplied  information  that  the  complaint  is  "runs  rough  on  loading"  combined 
with  the  single  complaint  assumption.  As  a  result  Gas  and  Summary  are  run. 
The  value  of  the  conditions  in  Gas  are  (7  —  — ),  where  signifies  "did  not 
ask",  and  the  row 

If  (Y  ?  ?)  Then  -3 

matches.  This  is  the  result  of  asking  a  question  of  the  user.  So  now  the 
values  of  the  conditions  for  Summary  are  (1  -3)  which  matches 

If .(7  (Lt  0))  Then  -3 

and  the  value  of  Summary  is  -3,  causing  Bad-Cas  to  reject. 

For  more  detail  about  CSRL  see  [Z]  and  [1]  . 

3.4.  Usefulness  of  CSRL  in  Developing  Auto-Mech 

One  of  the  first  things  we  noticed  in  using  CSRL  is  that  the  internal 
workings  of  a  specialist  and  the  overall  problem-solving  method  is  easy  to 
explain  to  a  computer-naive  expert.  Establish-refine  seemed  to  be  a  natural 
way  for  the  experts  to  solve  the  problems  and  was  not  in  any  way  imposed  upon 
them.  The  specialists  in  the  diagnostic  hierarchy  of  Auto-Mech  represent  the 
hypotheses  considered  by  the  experts  during  the  solution  of  practice  problems. 
The  experts  quickly  understood  the  CSRL  specialists  and  could  point  out  flaws 
in  their  reasoning  during  debugging  sessions. 


*0ur  experts  were  Ph.D.  students  in  Nuclear  Engineering,  they  were  not 
computer  specialists  and  knew  very  little  about  AI. 
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Another  helpful  feature  of  CSRL  is  that  it  makes  it  easy  to  get  something 
running  quickly.  This  gives  the  experts  a  chance  to  actually  run  the  program 
to  see  the  results  of  their  suggestions.  It  is  much  easier  for  experts  to 
help  debug  a  running  program  than  to  debug  a  paper  construct.  CSRL  makes 
possible  the  development  of  partial  systems,  the  obvious  evidence  for  which  is 
that  we  can  develop  a  fuel  system  program  without  being  concerned  with  the 
rest  of  the  car.  Much  of  this  is  due  to  our  approach  to  diagnosis  in  which 
knowledge  is  localized  within  specialists  and  the  interaction  among 
specialists  is  simple  and  well-defined.  Concerns  about  global  interaction  of 
knowledge  are  minimized.  Changes  in  the  Delivery  specialist  will  not  affect, 
any  other  specialists  in  the  hierarchy  (except  for  the  context  assumed  by  its 
subspecialists,  an  easy  thing  to  check).  So  if  Vacuum  works  right  but 
Delivery  has  bugs  in  it,  fixing  Delivery  will  not  affect  Vacuum.  This  greatly 
simplifies  building  and  debugging  a  system,  over  the  traditional  knowledge¬ 
base/  inference-engine  approach. 

Auto-Mech  consists  of  34  specialists  in  a  hierarchy  which  varies  from  four 
to  six  levels  deep.  Four  people  were  actively  involved  with  its  development, 
two  computer  specialists  and  two  domain  experts.  The  total  labor  was 
approximately  five  man-months  of  which  about  3  OX  was  domain  expert  time.  The 
project  extended  over  nine  calendar  months. 

3.5.  Some  Difficulties 

CSRL  was  built  to  embody  a  theory  of  diagnosis  which  was  developed  in  the 
medical  domain.  The  diagnostic  reasoning  of  an  automobile  mechanic,  however, 
is  slightly  different  from  that  of  a  doctor.  Once  a  hypothesis  is  confirmed  a 
doctor  will  carefully  consider  the  competing  refinement  hypotheses  and  follow 
up  on  the  best.  This  is  the  behavior  modeled  by  the  establish-ref ine  theory. 
But  an  auto  mechanic  seems  to  follow  up  the  first  reasonable  refinement. 
Auto-Mech  does  uot  capture  this  latter  behavior.  It  could  be  done  in  CSRL, 
though  it  *mld  be  a  little  more  difficult  to  do  than  using  the  standard 
establish-ref ine  routines.  The  end  result  of  diagnosis  in  both  cases  is  the 
same,  but  presently  Auto-Mech  seems  dumb  to  an  expert  since  it  is  being  more 
careful  than  necessary. 


Mechanics  usually  do  not  go  straight  into  the  kind  of  diagnostic  reasoning 
which  requires  a  diagnostic  hierarchy.  The  complaints  are  associated  with 
typical  maintenance  or  repair  procedures  as  a  result  of  the  training  or 
experience  of  the  mechanic.  An  example  of  this  is: 

Temperature  dependent  problems  (those  that  happen  only  when  the 
engine  is  cold,  or  only  when  it  is  hot)  are  usually  caused  by  a 
malfunction  of  the  choke.  So  for  those  problems  first  check,  to  see 
that  the  choke  works  correctly-  and  if  it  does  not  then  fix  it.  Also, 
since  you  have  to  go  past  the  air  filter  to  get  to  the  choke,  make 
sure  the  air  filter  is  good. 

Only  after  all  the  applicable  procedures  like  this  get  tried  does  the  mechanic 
do  the  more  serioqa  diagnosis  done  by  Auto-Mech.  This  process  is  outside  the 
scope  of  both  CSHL  and  the  establish-ref ine  theory  but  it  is  actually  only  an 
efficiency  measure.  The  final  diagnoses  using  the  mechanic's  method  and  using 
establish-ref ine  are  the  same,  with  establish-ref ine  possibly  doing  more  work. 


One  of  the  problems  we  had  in  developing  Auto-Kech  is  that  we  could  not 
treat  establishing  a  specialist,  or  confirming  a  hypothesis,  as  indicating  a 
high  degree  of  belief  in  the  hypothesis.  Sometimes  in  Auto-Mech  a  specialist 
establishes  because  it  is  not  possible  to  reject  it  and  one  of  its 
subspecialists  may  be  able  to  establish.  So  during  diagnosis,  when  a 
specialist  establishes  it  really  means  "this  hypothesis  is  worth  pursuing." 
This  is  mainly  due  to  the  type  of  domain  that  we  were  working  with.  Most  of 
the  data  used  by  Auto-Mech  are  very  weak  at  indicating  specific  problems. 
Data  that  are  direct  are  usually  about  tip  hypotheses  and  of  the  form  "is  xxx 
working  correctly."  Thus  the  specialists  which  rely  on  indirect  data  are 
unable  to  produce  high  confidence  in  their  associated  hypotheses,  although 
they  can  still  determine  a  "pursuit  value."  The  theory  of  establish-ref ine 
problem  solving,  which  CSBL  is  based  on,  needs  to  be  modified  to  take  this 
into  account. 


The  question  of  when  to  stop  is  a  difficult  one  for  diagnosis  in  general. 
Hunan  experts  have  the  concept  of  a  diagnosis  "explaining"  the  data  and  that 
certain  data,  must  be  explained  while  other  data  need  not  be.  Automating  this 
decision  has  proven  to  be  difficult,  though  it  seems  clear  that  it  is  not  a 
decision  appropriately  made  by  the  diagnostic  expert  itself  but  rather  by  some 
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outside  entity  having  additional  knowledge  and  skills .  This  is  why  CSRL 
currently  asks  if  the  user  is  satisfied  as  control  passes  back  up  through  the 
hierarchy.  However,  in  the  automobile  domain  the  system  should  recommend 
fixing  the  problems  represented  by  established  tip  specialists  and  then  ask  if 
the  problem  persists  after  the  repairs  are  made.  The  answer  to  that  question 
could  be  data  for  another  round  of  diagnosis.  Once  again,  this  could  be  fixed 
within  CSBL  (the  problem  arises  from  the  built-in  Simple-Refine  macro  which 
was  designed  to  be  very  general  and  would  need  to  be  customized  for  Auto- 
Mech) . 

In  the  eatablish-ref ine  theory  of  diagnostic  problem-solving,  diagnosis  is 
seen  as  an  inherently  parallel  process  [5].  All  specialists  at  a  given  level 
in  the  hierarchy  may  be  active  simultaneously .  These  specialists  communicate 
their  status  (established  or  rejected)  to  each  other  via  a  blackboard.  This 
makes  it  possible  for  a  specialist  to  know  what  another  specialist  has  done. 
Sometimes  this  knowledge  is  necessary,  as  can  be  seen  in  the  example  session 
given  earlier  where  the  Fuel  specialise  wanted  to  know  the  status  of  the 
Ignition  specialist.  CSRL  is  presently  implemented  as  a  serial  language 
without  a  blackboard.  This  leads  to  some  occasional  awkwardness  as  the  Fuel 
specialist's  question  to  the  user  shows. 

Another  feature  of  eatablish-ref ine  theory  is  that  it  is  strictly  a  theory 
of  class if icatory  reasoning  and  that  other  kinds  of  reasoning  are  needed  to  do 
diagnosis.  In  particular  inferential  reasoning  about  data  is  needed.  For 
example,  if  the  user's  problem  is  one  which  involves  the  engine  running  then 
the  system  should  know  that  there  is  fuel  in  the  tank  even  if  that  piece  of 
data  is  not  explicitly  given  to  it.  This  is  reasoning  about  relationships 
between  pieces  of  data  and  is  not  class  if  icatory  in  nature.  In  MDX  there  is 
an  intelligent  data  base  component,  called  PATREC  [6,  7],  for  doing  such 
reasoning  about  medical  data.  CSRL  is  intended  to  be  used  for  the  diagnostic 
component  and  so  it  does  not  contain  an  intelligent  data  base.  Since  this 
component  is  absent  in  Auto-Mach,  we  have  had  to  clutter  our  diagnostic 
specialists  with  data  base  reasoning. 


4.  Summary  and  Recommendations 

The  relative  length  of  the  "dif ficulties"  section  compared  to  the 
"usefulness”  section  is  due  to  the  need  for  additional  programaing  and  the 
CSRL  language  rather  than  deficiencies  in  the  theory  of  diagnostic  problem¬ 
solving.  The  difficulties  point  to  some  recomendations  for  improvements  in 
CSRL: 

1.  Changes  from,  the  standard  control  flow  should  be  easier  to  make. 
Presently  all  hypotheses  at  one  level  are  tried  before  going  down 
to-  the  next  level.  The  control  needed  by  Auto-Mech  is  a  natural 
compleawnt  to  this  —  pursue  the  first  reasonable  hypothesis. 

2.  CSRL  needs  a  more  flexible  facility  for  determining  when  to  stop 
than  simply  asking  the  user.  System  builders  may  have  ideas  on  how 
to  do  it  for  specific  problems  without  necessarily  being  able  to 
solve  the  general  problem  of  deciding  when,  diagnosis  is  complete. 

3.  Since  CSRL  is  to  be  used  for  building  diagnostic  experts  it  should 
provide  a  facility  for  limited  communication  between  specialists 
across  the  hierarchy,  such  as  a  blackboard.  Such  a  facility  would 
be  useful  even  if  CSRL  remains  a  serial  language. 

Our  other  problems  were  the  result  of  things  which  it  would  not  be  appropriate 
for  CSRL  to  address  since  they  are  outside  the  scope  of  classificatory 
diagnosis.  These  include  the  intelligent  data  base  and  the  execution  of 
typical  maintenance  procedures  prior  to  diagnosis. 

Overall  CSRL  was  a  very  useful  tool  for  developing  a  diagnostic  expert 
system.  It  was  easy  to  explain  to  an  expert,  the  specialists  were  fairly  easy 
to  write  based  on  protocols,  and  a  partial  system  could  be  running  quickly  for 
debugging  purposes.  CSRL  was  also  easy  to  use  from  a  programmer's  point  of 
view. 

Auto-Mach  does  not  verify  the  validity  of  establish-ref ine  problem-solving 
but  it  does  demonstrate  that  establish-refine  is  a  viable  method  for  doing 
diagnosis.  It  is  a  natural  way  for  experts  to  solve  problems.  The  hypotheses 
they  consider  can  ba  used  as  specialists  within  the  diagnostic  system.  The 
localization  of  knowledge  proved  to  be  useful  for  development  purposes. 
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ABSTRACT 

Moat  of  tha  diagnostic  systems  that  have  baan 
developed  in  aadiciaa  aa  wall  aa  othar  domains  can 
proparly  ha  cal lad  "compiled"  knowledge  systems  in 
tha  aaaaa  Chat  tha  knowledge  baa  a  containa  tha 
ralationahipa  between  symptoms  and  malfunction 
hypothaaaa  in  ua<  form.  Imwr,  often  in  human 
reasoning,  an  expert's  knowledge  of  horn  tha  device 
"functions”  ia  uaad  to  aanarata  now  ralationahipa 
daring  tha  reasoning  procaaa.  Thia  daapar  level 
rapraaantation  which  can  bn  procaaaad  to  yiald  aura 
compiled  diagnostic  •tractor aa  ia  tha  concern  of 
thia  paper.  lining  tha  azanpla  of  aa  bona  ahold 
burner,  wo  ahem  ia  thia  papar  what  a  functional 
rapraaantation  of  a  dawica  looka  like.  8a  alao 
indicate  tha  nature  of  the  compilation  procaaa  that 
can  produce  tha  diagnoatic  export  from  thia  deeper 
rapraaantation. 


1.  Introduction 

Recently  tha  domain  of  dawicaa  haa  attracted 
theoretical  aa  wall  aa  applied  AI  raaaarchara  [1, 

2,  3,  A,  13,  14,1(1.  To  troublaahoot,  modify  and 
monitor  dawicaa  (ag.  nuclear  power  plant, 
phyaio logical  organa,  electronic  circnita,  computer 
•of twara,  ate.),  it  ia  oacaaeary  for  aa  agent  to 
rapreoeat  and  nan  tha  knovladga  about  the 
functioning  of  tha  dawicaa.  Mor mower,  an  agent 
naeda  to  know  tha  functioning  of  ainilar  dawicaa  ia 
order  to  bacomo  an  expert  in  doaigning  a  new 
dawica. 

Inferring  to  tha  "depth"  of  knovladga  ia  expert 
eyatana.  Hart  [31  and  Micbie  [(]  bare  auggeated 
that  cyataaM  with  daap  knovladga  vill  be  able  to 
aolwa  problema  of  significantly  greater  complexity 
than  the  ao  called  aurfaca  aye tana.  Their  remark* 
on  daap  wa.  aurfaca  ayetana  a  earn  to  capture  a 
fairly  vidaapracd  foaling  about  the  inadequacy  of 
tha  firat  generation  expert  ayetana.  Hovewer,  ia 
Chandxaaekaraa  and  Mittal  [7],  it  ia  argued  that, 
ia  principle,  giwan  any  deep  modal  of  a  domain,  it 
ia  poaaibla  to  compile  aa  expert  diagnoatic  ayatan 
(more  a pacifically  aa  MDX-lika  diagnoatic  ayatan 
(8,  9,  171)  which  ia  aa  powerful  aa  the  deeper 
model,  but  more  efficient  than  the  deeper  model  for 
diagnoetic  purpoaea. 

Alao,  there  ia  ao  general  agreement  on  tha  form 
and  content  of  thane  deep  knovladga  atructurea . 
Hart  [31  auggaaea  that  they  ahould  model  eauaality 
by  multi-level  ayetana,  while  Michie,  following 


Rouaa  [101,  propoaea  that  they  ahould  repreaent 
knovladga  of  the  form  "aituation  x  action  -> 
aituation".  Tha  work  of  ?atil  [11]  and  Pople  [121 
ia  baaed  on  tha  idea  that  tha  appropriate  form  for 
tha  repreaentation  of  deep  knowledge  ia  a  caueal 
net.  8a  propone  that  with  reapect  to  the  "aurfaca 
eauaality"  modeled  ia  ayetana  like  KTCH,  the  next 
deeper  level  to  modal  eauaality  ia  the  functional 
rapraaantation  of  dawicaa.  Aa  agent  beconea  an 
expert  in  varioua  taaka  auch  aa  diagaoaia,  daeign, 
explanation,  ate.,  by  compiling  appropriate  problem 
aolwing  atructurea  from  the  functional 
rapraaantation . 

la  thia  papar  we  deacribe  a  representational 
a  chau  for  the  functioning  of  dawicaa  and  ita 
utility  for  compiling  an  MDX-lika  [8,9,  17  ] 
diagnoatic  expert  ayatan.  Our  focua  here  ia  on  tha 
representation ;  we  diacuaa  the  compilation  in  more 
detail  in  [131. 


2.  Comparison  with  Rain tad  Research 

Da  kleer  and  Brown  [1,  2,  31  have  bun  working 
on  the  repreaentation  of  an  agent's  knowledge  about 
how  a  device  actually  functions .  Thia 
rapreaentation,  which  they  call  "functional",  is 
actually  a  eauaally  related  sequence  of  behavioral 
states,  sou  of  which  either  belong  to  the 
components  or  refer  to  the  attributee  of  the 
interconnections  betvun  the  components .  They  then 
proceed  to  discus*  the  process  of  acquiring  tha 
above  "functional"  representation  from  the 
structural  knovladga  of  the  device.  They  iapose 
thru  interesting  critaria  that  such  a  procaaa,  as 
ull  aa  the  "functional"  repreaentation,  should 
satisfy  —  namely,  "uo-f one tion-in-s  tructure " , 
"weak  causality”  and  "strong  causality.” 

Our  work  differ*  from  that  of  Do  kleer  and  Brown 
ia  two  aspects:  firstly, our  definition  of  what 
constitutes  a  functional  representation  is 
different  from  their*.  Secondly,  while  they  are 
concentrating  on  the  acquisition  of  function  from 
structure,  we  wish  to  understand  the  process  by 
which  an  agent  uses  the  functional  representation 
for  various  problem  solving  activities,  i.a., 
transforms  the  functional  representation  into 
"expert”  problu  solving  atructurea.  However, 
these  apparently  different  objective*  are  not  aa 
disjoint  as  they  night  appear.  la  fact,  we 
strongly  believe  that  our  functional  representation 
vill  ultimately  satisfy  the  twin  requirements  of 
sequirability  and  trsnsformability  into  expert 


problw  solving  icnctuu 


lb*  functional  representation  of  Dari*  at  al 
(131  has  "functional"  aa  vail  aa  "physical" 
hierarchies .  Thair  "inf aranca  rnlaa"  and 
"simulation  rnlaa"  aaabla  thair  "viola  tad 
azpactation"  approach  Co  CronblaahooCing.  Hovavar, 
chair  "functional"  and  "physical"  hiararehiaa 
naichar  diffarantiata  nor  ralata 
"f  unction" , "a  crnctora" , "behavior " ,  "aa  sumptions " 
and  "daapar  eanaal  Knowledge  ”  aa  onra. 


3.  A  tapraaancacional  Schana  for  Cha  rnnetioning  of 
Davicea 


3.1.  Tha  tapraaancacional  Schaaa 

Our  scheme  allow  aalciplicity  of  lavala  in 
fnaccional  rapraaantation.  Tha  eopaoae  laval 
daacribaa  cha  functioning  of  a  device  in  tame  of 
cha  abacraceiona  of  ica  conponanta.  Tha  oast  laval 
daacribaa  cha  functioning  of  thaaa  conponanta  using 
Cha  abatractioaa  of  Chair  subcomponents ,  and  ao  on. 
Aa  ve  shall  saa  later,  Cha  hierarchy  is  not  just 
functional.  Tha  abstractions  fraai  Cha  lover  laval 
include,  in  addition,  tha  atacaa  of  components  as 
wll  as  ocher  entities. 

Ac  each  laval  of  our  functional  rapraaantation 
va  propose  that  there  are  five  significant  aapaces 
to  an  agent's  knowledge  of  functioning  of  devices: 

-  SIStfCTUU;  chat  specifies  tha  conponanta 
(subcomponents)  of  a  device  (a  component ) 
and  tha  interconnections  between  than. 

-  FOICTIOI:  that  specif ias  WHAT  is  Cha 
response  of  a  device  or  a  component  to  an 
asternal  or  internal  stimulus . 

-  SCLAV IOt:  that  specifies  HOW,  given  a 
stimulus,  cha  response  is  acconpliahad. 

-  comic  nOHUDCK:  chunks  of  deeper 

causal  knowledge  that  have  bean  compiled 
from  various  domains  to  aaabla  tha 
specification  of  behavior  of  devices  and 
thair  conponanta.  For  example,  a 

specialised  version  of  tirchof f's  lav 
from  tha  donain  of  electrical  circuits. 

-  ASSOMFTIOU:  under  which  a  behavior  is 
acconpliahad. 

■ext  we  describe  tha  rolas  of  thaaa  five  aspects 
in  representing  tha  functioning  of  devices  sad 
thair  notations .  Following  Da  kleer  and  Brown  (1, 
2],  w  shall  use  tha  household  busier  shown  in  fig. 
3-1  to  illustrate  our  ideas. 


Figure  3-1:  A  Schana tic  Diagram  of  a 
Household  Bursar 


TOICTIOH 

Tha  functional  specification  of  a  device  is 
illustrated  below  by  describing  one  of  the 

functions  of  the  bussar. 

FOICTIOI: 

Buss:  TOMAKX  bussing(bussar) 

IF  pressed (annual-switch)* 

FIOTISBD  assumption^  BT  bahaviorl 

"buss”  is  tha  asms  of  the  function; 
"bussing (busier )"  denotes  the  bussing  stats  of  tha 
busier.  "t7"  and  "t8”  are  distinguished  a laments  of 
a  component  of  bussar  (w  discuss  this-  below). 
”assunption2"  will  spacify  tha  initial  state  i.a., 
"t7”,”tS"  are  electrically  connected  (more  about 
assumptions  later).  Tha  "IT"  clausa  rslatas  tha 
function  with  its  behavior  i.a.,  the  aannar  in 
which  tha  function  is  acconpliahad  (behavioral 
specification  is  daacribad  below) .  As  ve  shall  sea 
in  section  4.2,  this  -  association  between  function 
sad  behavior  is  important  at  the  compilation  stage. 

UBZSZStt 

The  structure  of  a  device  (component)  is 
represented  using  the  abstractions  of  its 
conponanta  (subcomponents)  and  generic  relations 
between  than  (such  as  "serial ly-coaaaeted" ) .  As  an 
illustrstion  consider  tha  structure  of  the  bussar 
given  below: 
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STDCTSU: 

coworats: 

manual-switch  (tl,t2),  battery  (tJ,t4), 
coil  (t3,t6,spacel),  clapper  (t7,t8,*pace2) 
amTTrmx  ■  serially-connected  (manual-switch, 
battery , coil, clapper ) 

AD  include!  (epacal  , space!) 

A33T1ACTZ0BS— OF-COMPOBEBTS : 

compos nn  clapper  (ti,I2, space) 

rmCTlOSS :  mechanical, acoustic, magnetic 
STATES:  elect-connected  (T1,T2), 
repeated-bit ( clapper ) 

a w  coupon*? 

coMPorarr  coil  (n.n.uia) 


e)  We  nodel  intercoanectioae  between 
coaponents  by  relations  such  as 
'serially-connected',  'includes',  etc. 

Tbs  behavioral  specification  of  a  device 
describes  the  manner  in  which  a  function  is 
accomplished  by  "gluing"  together  the  functions  of 
components,  generic  knowledge,  assumptions  relating 
to  behavioral  alternatives,  and  sub-behaviors.  For 
sxample,  the  specification  of  of  'behaviorl'  in 
fig.  3-2  illustrates  how  the  'buss'  function 
discussed  above  is  realised. 


ed  ooHNaart 

on  absteactiobs-of-compobeits 
ID  STBDCIBU 

"tl",t2*....,  "space"  are  distinguished  elements 
(terminals)  of  eoaqrauents  ;  only  between 
distinguished  elements  can  relations  be  dafinad. 
"mechanical", "acoustic",  etc.,  are  the  nemos  of 
functions  of  clapper.  These  functions  (  as  wall  as 
the  structure,  behavior,  generic  knowledge  and 
assumptions  relating  to  the  clapper  as  well  as 
other  of  the  components)  are  represented  at  the 
next  level  of  our  representation  in  the  seme  manner 
as  che  busser.  The  capitalised  parameters  such  as 
Tl,T2,atc.,  are  local  to  che  associated  component. 


ttmrms  baSsvlsrl 

PtMMd  (iMMll-Wfltefc)* 

5T  o«tacvlar2 

{•Iftct-coaMCca*  (tj,  eg);  v«l«cc~«oflMce*d  (t?.  cg}}* 

osoc  fljscnov  M«eh— teal 

or  zl*pp*r  {t7.  «p»c*2) 

UpMC«4-hlc  (cXappM) 


It  is  important  to  note  the  following: 


a)  A  component  (subcomponent)  is  specified 
independent  of  the  representation  of  the 
device  (component)  which  contains  it. 
More  specifically,  the  specification  of 
a  component  does  not  refer  to  the  role 
of  the  component  in  che  composite.  Thus 
onr  representation  obeys  the  "uo- 
f unction- in-* true Curs"  principle  of  De 
kleer  and  Brown  [1,  21. 


b)  Sot  the  behavioral  specifications  of 
components  but  only  the  names  of  the 
functions  ere  carried  over  to  the  higher 
level.  This  property  is  important  when 
an  agent  needs  to  replace  a 
malfunctioning  component  by  s 
functionally  equivalent  but  behavioral iy 
different  one.  Bote  that  neither  the 
"intrinsic  mechanism"  nor  the  "causal 
model"  of  De  kleer  and  Brown  [1] 
distinguishes  between  function  and 
behavior  as  we  do.  The  "behavioral 
description"  of  Davis  et  el  (131  and 
Davis  [14]  is  similar  to  our  functional 
specification.  They  da  not  have  any 
construct  equivalent  to  our  behavioral 
specification.  (The  significance  of 
having  e  behavioral  specification  will 
become  clear  when  we  discuss  it  below.) 


Be  have  made  use  of  five  conceptually  important 
notations  in  behavioral  specification.  They  are 

described  below: 

1:  si 

II 

1 1  Bt  <name-of-a-behavior> 

\/ 

s2 

Tor  example, 

Pressed  (manual-switch)* 

II 

1 1  BT  bebsvior2 

\/ 

elect-connected  (t7,t8);  . 

“  elect-connected  (t7,t8)L* 
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Thii  miu  that  th*  luu  «1  causa*  th*  stata  *2 
a ad  th*  da call*  art  in  another  behavioral 
•pacification  (  "bebavior2") .  Ibis  cslseiou 
enables  tbs  Cba  (pacification  of  behavior  of  a 
coaponant  (or  a  device)  at  uany  levels  of  datail 
but  still  at  tba  level  of  tba  coaponaut  (or 

device) . 

2:  cl 

II 

1 1  OSIMC  TOICTIOB  <neae -of-a-function> 

1 1  Of  <coapoaant> 

\/ 

(2 

For  exaaple, 

rapaa tad-bit  (clappar) 

1 1  ITS  UK  FtnCTXOR  acoustic 
II  OF  clappar(t7>tS,spac*2) 

\/ 

bussing  (bussar) 

Tba  abora  notation  aaans  that  tba  stata  s2  ia 
causad  froa  *X  by  asking  us*  of  a  function 
("acoustic")  of  tba  caapoaant  (  clappar).  Ibis 
ralatioa  aakas  it  poasibla  to  glua  tba  functions  of 
tba  eoaponants  togatbar  to  obtain  a  behavior. 

3: 

SI  =  32 

Iba  abora  notation  aaans  that  tba  agant  will 
"equivalents"  tba  stata  si  of  a  caapoaant  (or 
subcomponent)  wi th  s2,  tba  stata  of  a  dorica  (or  a 
coaponant).  For  assnpla,  aa  in  tba  (pacification 
of  "bahaviorl"  (raf.  to  fig.  3-1  "bussing(elappar)" 
ia  "aquivalsncad"  with  "bussing (bussar)".  Beta 
chat  without  this  relation,  it  is  iapoasibl*  to 
conaact  tba  rasult  of  a  function  of  a  caapoaant 
(tba  bussing  of  tba  clappar)  with  tba  rasult  of  a 
function  of  tba  dawica  (tba  bussing  of  tba  bussar 
which  is  tba  rasult  of  its  function  "buss"). 
Without  this  connection,  "babswiorl"  cannot  ba 
claiaad  to  iaplaaaat  tba  function  "buss”  of  tba 

bussar. 

4:  si 

II 

1 1  AS-FSI  <naaa-of-a-fcaowladga-cbunk> 
1 1  a-Tax-cansn-CT  <  on*  or  aora 
\/  of  a  "ralatioa”,  "stata"  or  a 

*2  "function  of  a  coaponant"  > 

For  asaapla, 

alact-connactad(t7 , tS) 

II 

f  I  AS-PKZ  knowledge!  O-TRt-CCmTEB-or 
II  FU1CTI0I  woltaga  OF  b*ttsry(tl,t2), 

1 1  sarially-eonn*ctad(battery,coil, 

\/  clapper ,aanual-switcb) 
voltag*-appli*d(t3,t6) 

Ibis  aaans  that  if  the  tsxainals  t7  and  t8  art 
alactrically  eoaaactad,  than  woltaga  will  ba 


applied  between  tS  and  t6.  This  is  trua  as  par  th* 
knowledge  chunk  called  'knowledge!'  whan  it  is 
applied  in  tba  contest  of  battary,  coil,  clapper 
and  manual  twitch  being  serially  connected,  and  the 
battary  aakas  woltaga  awailabl*  at  its  tstninal. 
(Iba  representation  of  'knowladgal'  is  discussed 
below.)  It  is  through  this  primitive  that  tba  rola 
of  generic  knowledge  in  describing  a  behavior  is 
represented. 

3:  magnatis*d(spaca2) 

II 

I  I  OSIBG  FUBCIIOH  magnetic 

II  OF  clapp*r(t7,t8,spaca2) 

( I  WITH  assumpeionj 

\/ 

~alact-connactad(t7 ,t8) 

"assunption3”  will  specify  that  thara  exists  a 
fore*  F  such  that  if  tp*c*2  is  nagnatisad,  than  th* 
rssnlting  magnetic  fore*  will  ba  greater  than 
F.  Iota  tbs'.:  "ssaunption3"  doe*  not  specify  what  is 
F,  how  it  is  to  b*  realised  and  so  on.  Iba  "WITH” 
clausa,  lika  "PIOVIDED “ ,  relates  an  assunption  with 
tba  stata  transition.  However,  "WITH”  is  different 
froa  "F10TID ID"  sinca  it  ralatas  an  aaswption  that 
is  paasad  frem  a  dawica  (coaponant)  to  a  coaponant 
(aub-coaponaat)  while  "PIOVIDED"  ralatas  the  on* 
team  a  coaponant  (sub— coaponant)  to  tba  device 
(coaponant).  Also,  assumptions  ralatad  by  "WITH" 
clausa  can  ba  uaad  to  ask*  a  stata  transition 
deterministic. 

camic  DiowLgDGg 

a*  generic  knowledge  specification  of  a  device 
(coaponant)  dascribas  all  chunks  of  daapar 
knowledge  used  in  its  bahavioral  (pacification. 

Zb*  following  is  a  specification  of  'knowladgal'. 

GSnilC  nOWLEDGI: 
knowladgal : 

voltage— applied  (tl,t2) 

II 

1 1  AS- FEE  kirchoff't-law 
1 1  O-I8S-C0HTSXT-0F 
II  alact-connectad(tl,t3) 

1 1  *  *l*ct-conuectsd(t2,t4) 

\/ 

voltaga-appliad  (t3,t4) 

It  is  worth  noting  that  the  specification  of 
generic  knowledge  is  contaxt-frae.  The  context  in 
which  it  is  applied  is  s pacified  in  cb*  behavioral 
specification  (as  illustrated  above).  As  we  shall 
sea  soon,  thara  is  a  mechanism  ("ttFIEEECES")  by 
which  a  user  task  of  th*  functional  representation 
knows  wbara  to  look  for  tba  definition  of 
Eirehoff's  law. 

Ha  would  lika  to  draw  particular  attention  to 
tba  notion  of  GOTHIC  OTOHLSDCE  in  our 
representation.  Ibis  enables  us  to  capture  tba 
relation  between  functional  representation  and 
deeper  causal  knowledge.  Moreover,  without  an 
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explicit  link  with  fuch  generic  knowledge  it  it  not 
poeeible  to  eopport  the  recognition  of  incorrect 
application  of  euch  knowledge  during  "envisioning" 
[1,2,3].  Also  it  cannot  aupport  queries  relating 
to  the  role  of  each  knowledge  in 
aadaratanding,deecribing, explaining, etc.,  of  the 
behavior  of  dewicea. 

mammons 

All  saseeptious  wade  uae  of  in  the  behavioral 
•pacification  of  a  device  (component)  are  deacribed 
in  ASSUMPTIONS  aa  illuatrated  below  with  reference 

to  the  clapper. 

ASSUMPTIONS: 

DSTHXT20M8 : 

fl  •  ■agnatic-force  DUK-TD  aagnatixed(apace)  ABO 

12  -  apring-force  DUB-TO  loaded  (apring) 

ASSUKPTI0B1 : 

IP  aagaetised (apace)  TUB  fl  >  f2 

ASSUMPTI0B2: 

IP  “  wagnatiaadC space)  THU  fl  <  f2 
KBD  ASSUMPTIONS 

"apring-force"  and  "aagna tic-force"  are 
concepts;  we  diacnas  below  about  their  definition. 
The  primitive  "DUE-TO"  relataa  a  concept  with  a 
•cate  of  a  coaponant. 

Soto  that  though  Da  Ueer  and  Brown  [21  staca 
that  a  difference  between  a  novice  and  an  expert  is 
that  the  latter  haa  aada  explicit  all  the 
aaeaptiona  underlying  behavior  of  devices,  their 
causal  nodal,  unlike  our  functional  representation 
,  does  not  represent  explicitly  the  role  of 
assumptions  in  behavior. 


Clearly  an  agent's  knowledge  of  the  functioning 
of  devices  will  have  references  to  elements  of 
different  domains  ,e.g.,  electrical 

circuits, electro-magnetism  ,etc.  These  references 
are  specified  in  the  "UP BUI CIS"  part  of  our 

representational  sch«e  as  illustrated  below: 

urancu: 

POk  kirehoff's-lsw,  elect-connected 
UPlk-TO  elect-circuits 

POk  eagnatic-force  UPU-ID  electro-magnetism 

am  umucB 

Bote  that  we  do  not  yet  know  how  to  represent 
domains  such  as  "elect-circuits”,  "electro- 

nagnetiam",etc. 


4.  Compilation  of  a  Diagnostic  Expert 

The  principal  function  of  the  compiler  that  we 
•hall  diacusa  here  is  to  generate  a  diagnostic 
expert  from  the  functional  representation.  Checking 
the  correctness/  consistency  of  a  functional 
representation,  optimisation  of  the  generated 
expert  systems  are  also  significant  aspects  of  the 
compilation  process.  However,  for  want  of  space  , 
we  discuss  here  only  the  generation  of  an  MSX-lika 
diagnostic  expert.  Other  aspects  of  compilation 
are  discuaaed  in  [13]. 


4.1.  The  Structure  of  the  Generated  Diagnostic 
Expert  System 

As  shown  in  fig.  4-1,  the  generated  expert  is  a 
hierarchy  of  specialists.  Each  specialist 
corresponds  to  a  aalfunction  in  the  device  at  a 
certain  level  of  abstraction.  For  example,  a  bad 
clapper,  bad  serial  connection,  etc.  Specialists 
corresponding  to  more  general  or  abstract 
malfunctioning  are  higher  in  the  hierarchy.  For 
example, the  root  apecialiat  in  fig. 4-1  corresponds 
to  a  "malfunctioning  buaxar".  Its  three  sub¬ 
specialists  correspond  to  the  following  three 
■alfuactioaa  (only  the  first  one  is  shown  in  fig. 
4-1): 


1.  The  buaxar  does  not  buss  whan  the  eanual 
•witch  is  pressed. 

2.  A  bussing  buaxar  does  not  stop  bussing 
when  the  eaaual  switch  is  released. 

3.  The  buaxar  keeps  bussing  independent  of 
the  state  of  the  eanual  switch. 

•Every  specialist  has  knowledge  to  establish  the 
associated  ealfunctioeing  and  to  refine  it  by 
calling  its  sub-specialists.  The  knowledge  of  a 
specialist  is  in  the  form  of  three  types  of  rules: 
confirmatory  rules, exclusionary  rules  and 

i  eriiemlstlons.  (He  will  not  discuss 
"recossMndationa”  hare  since  it  is  concerned  with 
optimisation  of  the  generated  expert.)  For 
example, 

IF  elect-connected  (tl ,t2)  * 

~  voltage-applied  (t3,t$) 

TUI  confirm 

17  voltage-applied  (tS,t6)  TUI  reject 

A  aalfunction  is  diagnosed  top-down  by 
establishing  a  specialist  sod  refining  the 
■alfunetion  represented  by  it  by  calling  its  sub- 
specialists.  This  discussion  of  the  structuring 
and  functioning  of  the  diagnostic  expert  is  grossly 
simplified.  More  detailed  information  can  be 
obtained  from  [  8,  9  ] . 


WWW)? 


n  «-*e  _."k  a*i  .V  A'lA  _*s  ^  ; 


I?  Pr«M«d  (aaouAi-svlech)* , 
'v  bussing  (busssr) 


IT  «l«ct  MMCtMd,.  t,)* 
nOM  confirm 
OH  rojoct 


If  «oltngo-«ofllo4  (t,,  tj)*. 

onaaoeadCtf.  t8)* 
confirm 
L  ml  net 


Figure  4-1:  4a  Zranple  at  t  Goa orated 
Diagnoatic  Expert 


Therm  are  three  typea  of  malfunctioning  and 
hence  three  typea  of  apecialiats: 


1.  4a  an  aeption  night  hare  been  violated . 

The  epecialiat  aaeociated  with  it  ia 
called  aa  checker. 

2.  4  function  nay  not  be  functioning 
correctly.  The  aaeociated  apacialiot  ia 
called  a  function  checker . 

3.4  relation  between  conponenta  nay  not 
hold.  Por  exanple,  the  battery,  coil 
aad  clapper  nay  not  be  conaacted 
aerially.  Let  ua  call  the  epecialiat 
the  relation  checker. 


4.2.  The  Conpilatioa  Proceaa 

4t  the  atart,  the  conpiler  genarataa  the  root 
epecialiat.  The  root  epecialiat  naeda  so  knowledge 
to  eetabliah  itaelf.  The  fact  that  the  expert  ia 
invoked  leada  entonatically  to  the  aatabliehnent  of 
the  root  epecialiat.  The  conpiler  than  proceeaea 
the  variooa  functiona  of  Che  device  aad  genarataa  a 
fnactioa  checker  corraaponding  to  each  function. 
For  exanple,  given 


FBHCIICS: 

boas:  TQ9UEX  bnaaing(bnaxar) 

IP  praaaed(nanual-avitch)*  ST  behaviorl 

the  conpiler  will  generate  a  function  checker  with 

the  following  role: 

17  preaeed(aannal-evitch)*  *  ~buxxing(buaxer ) 
THES  coafim 
ELSE  reject 

Than  the  function  cheekara  generated  aa  above  will 
be  attached  to  the  root  epecialiat.  4fterwarda  the 
conpiler,  uaiag  the  ”BT”  clauae,  obtaina  the 
behavior  aaeociated  with  each  function  and  conpilea 
it.  Por  exanple,  if  the  behavior  ia  apecifiad  in 
the  torn: 

al  — >  e2  "■>  .  ■— >  an 

than  the  conpiler  will  generate  a  aet  of  u-1 
apecialiata  for  the  function  ehackera  aaeociated 
vith  the  behavior.  The  rulea  for  then  will  be: 

IF  al  *“  a2  SEE  confirm 
ELSE  reject 


IT  an-1 


an  TEES  confine 
ELSE  reject 
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For  eh*  "bun"  function  example  given  above,  nods* 
5,  6  and  7  in  fig.  4-1  will  b*  generated  ueing 
"behaviorl"  in  fig  .3-2 .  Bote  that  eh*  ml* 

associated  with  nod*  3  ahould  b*: 

If  prsssedCaanual-switch)* 

*{elmct-conancted(t7 ,t8) ;~*l*ce-conn*et*d(e7 , t8) }* 
1 3D  confix* 

EL3S  raj act. 

However,  eh*  condition  "pressed  (manual-switch)*"  it 
not  chackad  tine*  ie  ia  don*  at  nod*  2,  i.*.t  eh* 
par*nt  of  eh*  nod*  5 . 

Fur  tiler  proeeeeing  of  a  behavioral  epecif  ication 
d*p*nd*  on  th*  kind  of  composition  of  behavior . 

CASK  1: 

Assume  that  nod*  5  ia  g*n*rat*d  corresponding  to 
eh*  following  teat*  cr ana it ion  in  fig.  3-2. 

Pressed  (manual-switch)* 

II 

1 1  ST  behavior  2 

\/ 

(elect-connected(t7,t8)  j  '*lect-connect*d(t7,t8)}* 

Th*  above  etac*  tranaicion  will  alao  reaolt  in 
compiling  'Behavior!'  aa  described  above,  and 
attaching  th*  g*nerac*d  apacialiata  to  nod*  3. 

CASS:  2 

Let  the  a tat*  transition  in  fig.3-2corr**ponding 
to  nod*  6  ia  fig.A-1  hi: 

(elect-connected ( t7 , c8 ) ;  'elect— connected(t7 , t8 ) )* 

II 

1 1  tJSIHC  rraCTIOB  mechanical 
\/  OF  clapper(t7,t8,space2) 

r epee ted-bit (clapper ) 

After  generating  eh*  nod*  6  for  th*  a bora  a tat* 
transition,  th*  compiler  will  look  at  th*  function 
'mechanical'  in  eh*  functional  representation  of 
eh*  component  'clapper'  and  compil*  eh*  behavior 
associated  with  th*  function.  If  there  ia  no 
behavioral  epecif ication  for  th*  function,  nod*  6 
will  b«  a  tip  specialist.  If  th*r*  ia  on*  for  eh* 
function,  than  it  will  b«  compiled,  and  th* 
generated  sp«cialists  will  be  attached  to  nod*  6. 
If  th*  function  of  eh*  component  ia  implicated 
under,  sap,  "assumption!"  and  th*  ap*cif ication  of 
"aatumpeionl"  is  of  eh*  fora: 

U  s3  THAI  a4 

than  th*  additional  specialist  with  eh*  rul* 

I?  s3  *  "s4  THIS  confirm 
ELSI  reject 

will  b*  generated  and  attached  to  th*  nod* 


corresponding  to  eh*  abov*  transition.  An  example 
of  an  assumption  checker  is  nods  4  in  fig. 4-1. 

CASS  3: 

Th*  seat*  transition 

al 

I  I  AS-PE&  knowledgel 

II  n-THS-COHTZn-or  s3"*4...sa 

\/ 

a2 

will  raault  in  a  sat  of  sub-apaeialiats  with  eh* 
rules : 


IT  "S3  THEK  confirm 
ELSE  reject 

IT  ”*4  THE®  confirm 
ELSE  reject 


IT  "an  TXEI  confirm 
ELSE  reject 
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APPENDIX 
To  Che  paper 

"A  REPRESENTATION  FOR  THE  FUNCTIONING  OF  DEVICES 
THAT  SUPPORTS  COMPILATION  OF  EXPERT  PROBLEM  SOLVING  STRUCTURES" 


by  V.S.  Moor thy  and  B.  Chandrasekaran 

Details  of  the  functional  representation  of  FUNCTION:  buzz  of  the  buzzer 

NOTE:  We  have  represented  below  only  the  buzzer; 

Battery, coil, clapper  and  manual  switch  have  NOT  been  represented. 


DEVICE  buzzer 
FUNCTION: 

buzz:  TOMAKE  buzzing  (buzzer) 

IF  pressed  (manual-switch)* 

PROVIDED  INITIAL  elect-connected  (t7,t8) 
BY  behaviorl 

s t op— buz z : TOMAKE  “buzzing  (buzzer) 

IF  “pressed  (manual-switch) 

PROVIDED  INITIAL  buzzing  (buzzer) 

BY  behavior 5 


STRUCTURE: 

COMPONENTS : 

manual-switch  (tl,t2),  battery  (t3,t4), 
coil  (t5,t6,spacel),  clapper  (t7,t8,space2) 

RELATIONS: 

seria 1 ly-connect ed  (manua 1-switch , battery , coi 1 , clapper ) 
includes  (spacel,space2) 

ABSTRACTION  S-OF -COMPONENTS : 

COMPONENT  clapper  (T1,T2, SPACE) 

FUNCTIONS:  mechanical, acoustic, magnetic 
STATES:  elect-connected  (T1,T2), 
repeated-hit  (clapper) 

COMPONENT  coil  (T1.T2, SPACE) 

FUNCTIONS:  magnetic 

STATES:  magnetized  (SPACE),  voltage-applied(Tl,T2) 

COMPONENT  manual-switch(Tl ,T2) 

FUNCTIONS:  connect 
STATES:  elect-connected  (T1,T2), 
pressed  (manual-switch) 


COMPONENT  battery  (T1,T2) 
FUNCTIONS:  voltage 


BEHAVIOR: 


behavior 1 : 

pressed  (manual-switch)* 

II 

1 1  B7  behavior2 

II 

\/ 

{  elect-connected  (t7,t8);  elect-connected  (t7,t8)>  * 

II 

||  USING  FUNCTION  mechanical  OF 
II  clapper(t7,t8,spacel) 

II 

\/ 

repeated-hit  (clapper)' 

II 

I |  USING  FUNCTION  acoustic  OF 
II  clapper  (t7,t8,space2) 

II 
\/ 

buzzing  (  clapper) 

III 
III 

buzzing  (buzzer) 


behavior2: 

{  pressed  (manual-switch) 

II 

I  I  BT  behavior3 

II 
\/ 

‘elect-connected  (t7,t8) 

II 

I  |  AS-PER  Icnowledgel  IN-THE-CONTEXT-OF 

I  I  serially-connected  (battery, coil, 

I |  clapper, manual-switch) 

I |  FUNCTION  voltage  OF  battery 

\/ 

‘voltage-applied  (t5,t6) 

II 

1 1  BT  behavior4 

II 

\/ 

elect-connected  (t7,t8)  >  * 


behavior 3 : 


pressed  (manual-switch) 

II 

||  USING  FUNCTION  connect  OF 
| |  manual-switch  (tl,t2) 

II 

\/ 

elect-connected  (tl,t2) 

II 

I |  AS-PEB  know ledge 1  IN-THE-CONTEXT-OF 
j I  FUNCTION  voltage  OF  battery  , 

I j  serially-connected  (battery .coil, 

I |  clapper, manual-switch) 

II 

\/ 

voltage-applied  (tS,t6) 

II 

I |  BY  behavior4 

II 

\/ 

'elect-connected  (t7,t8) 


behavior 4:  IFF 

voltage-applied  (t5,t6) 

II 

I |  USING  FUNCTION  magnetic  OF 
II  coil  (t5,t6,spacel) 

II 

\/ 

magnetised  (space!) 

II 

I  I  AS-PEB  knowledge2  IN-THE-CONTEXT-OF 

II  includes  (spacel,space2) 

II 

\/ 

magnetized  (space2) 

II 

I |  USING  FUNCTION  magnetic  OF 
II  clapper  (t7,t3,space2) 

II 

\/ 

'elect-connected  (t7,t8) 


GENERIC  KNOWLEDGE: 
knowledge 1 : 

Voltage-applied  (tl,t2) 

II 

I  I  AS-PER  kirchoff's-law 

I |  IN-THE-CONTEXT-OF 

II  elect-connected  (tl,t3), 

I  I  elect-connected  (t2,t4) 

II 
\/ 

voltage-applied  (t3,t4) 


knovledge2 : 

magnetized  (spacel) 

I  I  AS-PER  laws-of-space 
I  I  IN-THE-CONTEXT-OF 

I  I  includes  (spacel, space2) 

II 
\/ 

magnetized  (space2) 


ASSUMPTIONS: 

DEFINITIONS : 

fl*  magnetic-force  DUE-TO  magnetized  (space) 
£2"  spring-force  DUE-TO  loaded  (spring) 

assumptionl : 

IF  magnetized  (space)  THEN  fl  >  f2 
assumption2 : 

IF  "magnetized  (space)  THEN  fl  <  £2 


END-DEVICE  buzzer 


To  /i*  CL  brffC  ^pJjirr^A  $*--**■ 

i*Q  lyJ  •  ^LvItv^jQ/k  ,  fH^fj/X  (jxty  -\>p  '/Ax^  . 

EXPERT  SYSTEMS :  MATCHING  TECHNIQUES  TO  TASKS 


B  Chandrasekaran^ 

Department  of  Computer  and  Information  Science 
The  Ohio  State  University 
Columbus ,  OH  43210 


ABSTRACT 

In  this  paper  an  attempt  is  made  to  relate  the  architectures  and 
representations  for  expert  systems  to  the  types  of  tasks  for  which  they  are 
appropriate.  He  start  with  an  analysis  of  the  features  that  characterise  an 
expert  system,  and  disenas  the  need  for  symbolic  knowledge  structures  that 
support  qualitative  reasoning  in  the  design  of  expert  systems.  We  consider 
rules,  logical  formulas  and  frames  for  representation  of  expert  knowledge.  In 
particular  we  provide  an  analysis  of  the  multiplicity  of  roles  that  rules  have 
played  in  different  rule-based  systems,  and  emphasise  the  need  to  distinguish 
between  these  rules.  We  proceed  to  outline  our  theory  of  types  of  expert 
problem  solving  and  argue  that  such  a  taxonomy  enables  one  to  characterise 
expert  system  capabilities  and  help  match  problems  with  techniques. 

Throughout  the  paper  it  is  emphasised  that  the  important  issue  is  the  nature 
of  the  information  processing  task  in  a  given  task  domain,  and  issues  of 
formalisms  for  representation  are  subordinate  to  that  basic  issue. 
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1.  KZrnX  SYSTEMS:  IHAI  All  THEY? 


It  is  clear  that  recently  artificial  intelligence  has  created  enormous 
excitement  in  the  commercial  marketplace,  and  one  of  the  sources  of  this 
excitement  is  the  promise  of  expert  systems  or  knowledge  based  systems  in 
solving  or  assisting  in  the  solution  of  many  practical  problems.  There  is  a 
widespread  feeling  that  knowledge  ia  the  next  frontier  in  the  practical 
application  of  computers,  and  the  well-publicized  commitment  of  the  Japanese 
to  research  on  and  development  of  a  Fifth  Generation  computer  for  knowledge 
proceseing  has  only  added  to  this  sense  of  an  impending  revolution.  The 
phraae  "expert  systems"  evokes  all  sorts  of  hopes:  From  the  clerical  worker  to 
the  research  scientist  in  a  corporation,  each  employee  is  a  storehouse  of  an 
enormous  amount  of  knowledge  and  problem  solving  capabilities.  The  syllogism 
goes  something  like,  "I  need  an  expert  for  Z,  they  are  hard  to  find  or 
expensive,  thus  I  need  an  expert  system  for  Z."  It  is  clear  to  most  of  us 
doing  research  in  the  field  that  while  the  promise  of  carefully  deployed 
expert  systems  is  indeed  high,  we  are  nowhere  near  the  stage  where  we  can  hope 
to  replace  all  kinds  of  human  experts  with  computer-based  expert  systems .  To 
take  an  extreme  example,  advanced  researchers  or  creative  mathematicians 
clearly  perform  knowledge-based  expert  problem  solving,  but  equally  clearly 
the  state  of  the  art  in  expert  systems  is  not  up  to  replacing  them  with  expert 
systems.  Any  attempt  to  characterize,  even  if  informally,  what  sorts  of 
problems  are  aswnable  to  current  techniques  --  matching  techniques  to  tasks, 
if  you  will  —  could  be  very  useful. 

A  related  problem  is  that,  in  strict  definitional  terms,  it  is  hard  to  be 
very  precise  about  what  characteristics  of  a  computer  progrsm  to  solve  a  class 


o£  problems  qualify  it  to  be  called  an  expert  system?  The  following 
dimensions  have  often  been  suggested  as  important  in  such  a  definition. 

-  Expertise  :  Certainly  a  necessary  condition  is  that  an  expert 
system  should  have  expertise  in  the  domain  and  show  expert-level 
performance  is  some  aspects  of  the  domain.  However,  this  condition 
is  not  sufficient.  Is  a  payroll  program  written  in  Cobol  an  expert 
system?  In  some  real  sense  it  captures  the  expertise  of  an 
accountant  whose  domain  knowledge  is  incorporated  in  the  many 
branching  decisions  made  by  the  logic  of  the  program. 

-  Search:  The  intuition  that  a  program  must  do  some  search  in  a  space 
of  possibilities  —  following  the  idea  that  search  is  an  essential 
characteristic  of  intelligent  reasoning  —  is  generally  useful  but 
not  always  valid,  because  Hi  (McDermott,  1982),  an  expert  system 
that  has  been  very  successful  in  practical  use,  does  not  do  any 
search  in  the  execution  of  its  main  task. 

-  Uncertainty:  While  uncertainty  in  data  or  knowledge  gives  many 
expert  problem  domains  (such  as  medicine)  interesting  additional 
properties  and  makes  them  challenging  for  the  deeigner  of  expert 
eystans,  it  is  not  a  defining  characteristic,  since,  again  using  HI 
as  an  example,  its  knowledge  and  data  do  not  involve  probabilistic 
or  other  types  of  uncertainty. 

-  Symbolic  knowledge  structures:  Most  expert  systems  in  the  AI  field 
have  their  domain  knowledge  in  explicitly  symbolic  form  as 
collections  of  facts,  rules,  frames  etc.,  which  ere  explicitly 
manipulated  by  problem  solving  or  inference  mechanisms  to  produce 
answers  to  questions.  This  is  to  be  contrasted  with  mathematical  or 


simulation  models  or  mainly  numerical  information  as  its  main 
knowledge  base.  However,  many  well-known  expert  systems  such  as 
Internist  represent  the  balk  of  their  core  knowledge  in  the  form  of 
numerical  relations  between  entities.  As  an  incidental  observation, 
we  may  note  that  the  general  emphasis  in  expert  systems  work  on 
symbolic  knowledge  structures  often  elicits  another  sort  of 
response.  Engineers  trained  in  mathematical  modelling  techniques 
find  it  difficult  to  understand  why  a  computer  program  which 
evaluates  say  a  system  of  complex  mathematical  equations  describing 
some  process  (such  as  nuclear  reaction  in  a  reactor  vessel)  is  not 
an  expert  system  —  after  all,  they  argue,  such  a  system  is  an 
embodiment  of  very  highly  specialised  expert  knowledge,  capable  of 
providing  answers  to  a  number  of  questions.  Further  thare  is  a 
tendency  among  some  people  in  this  group  to  regard  AI  programs  as 
"approximate,"  because  the  rules  that  an  expert  system  will  use  are 
supposed  to  be  only  heuristic,  while  the  mathematical  models  are 
exact.  (See  sec.  3.2  for  a  discussion  of  this  issue.) 

Explanation  capability:  Continuing  in  the  vein  of  searching  for 
definitional  characteristics  of  expert  systems,  the  idea  that  such 
systems  should  be  able  to  explain  their  reasoning  is  a  useful 
constraint  on  the  structure  and  functioning  of  expert  systems,  but 
as  a  rule,  since  the  activity  of  explanation  itself  is  poorly 
understood,  it  is  not  yet  certain  what  structures  and  functions  this 
requirement  rules  out  or  permits. 

Other  features:  Many  people  in  the  industrial  world  have  virtually 
taken  to  defining  expert  systems  as  those  that  have  a  knowledge  base 


*nd  a  separate  inference  engine,  and  that  knowledge  base  in  expert 
systems  should  necessarily  be  in  the  fora  of  roles .  Again,  while 
roles  hews  been  a  dominant  aethod  for  knowledge  representation  in 
aany  first  generation  expert  systems,  many  expert  systems  have  used 
frame  structures  (Pauker,  Gorry,  Cassirer,  Schwartz,  1976),  or 
network  structures  (Duda,  Gaschnig,  Bart,  1979).  In  any  case,  this 
emphasis  on  knowledge  representation  foraa lisas  often  obscures  the 
more  fundamental  issues  of  the  content  of  the  computation  these 
systems  do.  For  example,  Ssolovits  and  Pauker  (1978)  point  out  that 
MXCH,  the  system  most  widely  thought  of  as  a  prototypical  example 
of  the  role-based  approach  can  be  recast  as  a  frame-based  system 
which  uses  procedural  attachments  to  fill  the  slots  in  various 
frames.  Taking  up  the  knowledge  base/  inference  engine  separation 
issue,  it  is  unlikely  that  a  complete  separation  of  knowledge  and 
inference  is  viable  as  a  basic  principle  in  the  organization  of 
expert  systems.  We  (Gomes  and  Chandrasekaran,  1981;  Chandr asekaran , 

1982)  as  well  as,  more  recently,  others  (Davis,  1982;  Stef ik,  et  al, 

1982)  have  argued  that  knowledge  and  its  use  are  likely  to  be  more 
strongly  intertwined  as  the  difficulties  and  variety  of  the  tasks 

2 

There  is  a  general  problem  in  AI  of  not  making  clean  distinctions  between 
the  basic  information  processing  task  of  a  computation  and  the  algorithm  or 
program  that  carries  out  this  task.  Marr  (1976)  presents  arguments  for  such  a 
distinction  in  computational  theories  of  vision.  In  Gomez  and  Chandrasekaran 
(1981)  we  make  analogous  arguments  in  the  area  of  knowledge  representation  for 
problem  solving  systems.  Saying  that  System  A  uses  rules,  while  System  B  uses 
networks  for  knowledge  representation  says  nothing  about  the  nature  of  the 
information  processing  activities  that  go  on  in  the  two  systems:  a  comparison 
at  the  formalism  level  would  miss  many  important  aspects  of  the  similarities 
and  differences  that  ought  to  be  sought  at  a  higher  level.  Our  discussions 
later  in  the  paper  regarding  roles  elaborate  on  some  aspects  of  this  point. 


the  expert  systems  are  called  upon  to  perform  increase.  (This 


argument  will  be  elaborated  in  Sec.  7  of  this  paper.) 

The  point  of  the  foregoing  is  not  to  suggest  a  precise,  issue-settling 
definition  of  expert  systems,  but  merely  to  point  to  the  multiple  dimensions 
along  which  expert  systems  can  be  viewed,  and  to  the  need  for  more  careful 

analysis  of  much  of  the  terminology  that  is  used  in  discussing  expert  systems 
The  major  line  of  argument  that  we  will  pursue  in  this  paper  can  be 
outlined  as  follows.  In  Sec.  2,  we  briefly  trace  the  development  of  the  idea 
of  knowledge-based  systems  in  AI.  Sec.  3  is  devoted  to  discussing  the 


increasing  need  for  symbolic  content  to  expert  reasoning  as  the  size  and 
demands  of  the  task  domain  increase;  i.e,  we  will  analyze  why  a  complete 


mathematical  model  of  the  situation,  even  if  available,  will  not  meet  many  of 
the  demands  placed  on  expert  reasoning.  In  Sec.  4,  we  discuss  the  several 
distinct  senses  and  roles  that  the  notion  of  rales  can  play  and  have  played  in 
expert  systems,  and  how  a  failure  to  keep  these  separate  can  cause  a  great 
deal  of  confusion.  In  Sec.  5,  we  briefly  discuss  logic-based  and  frame-based 
representations.  In  Sec.  6,  we  discuss  the  need  for  organization  of  knowledge 
for  effective  use,  and  in  Sec.  7,  we  argue  that  further  organizational 
constructs,  such  as  concents  and  types  of  problem  solving,  are  needed  both  to 
construct  more  powerful  expert  systems,  and  to  characterize  their 


capabilities.  This  will  also  have  the  side  effect  of  emphaeizing  the 
increasing  need  not  to  separate  knowledge  bases  and  inference  machineries.  We 


will  also  provide  in  this  section  two  examples  of  generic  problem-solving 
types,  and  show  how  each  type  of  problem-solving  induces  an  organization  of 
knowledge  in  the  form  of  a  cooperating  community  of  "specialists"  engaged  in 


V*,  '  /  . 
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Chat  problem  so lying  type.  At  this  point,  we  vill  be  able  to  discuss  what 
sorts  of  problems  can  be  handled  by  "compiled"  structures  and  what  sorts  need 
"deeper"  problem  so lying.  In  that  context  we  vill  discuss  the  issues  related 
to  the  so-called  causal  modeling  problem.  This  vill  help  us  present  a 
discussion  of  the  the  issues  surrounding  the  degree  of  understanding  that 
expert  systems  may  need  to  have  about  the  domain.  The  overall  flow  of  the 
discussion  is  in  the  direction  of  the  evolution  of  expert  systems  from 
nnmsrieal  programs  to  highly  organized  symbolic  structures  engaged  in  distinct 
types  of  problem-solving  and  communicating  with  one  another. 

An  admission  is  in  order  at  this  point.  The  title  is  more  ambitious  than 
vhat  ve  vill  be  able  to  accomplish  in  this  paper.  A  really  satisfactory 
account  must  await  a  better  overall  theory  of  problem  solving  than  ve  have  at 
present'.  Even  an  incomplete  theory  such  as  the  one  presented  in  Sec.  7  is 
capable  of  providing  a  framework  for  characterizing  capabilities  of  expert 
systems  in  generic  terms.  Thus  the  paper  should  be  viewed  as  stating  a 
position  on  the  sorts  of  theories  that  might  help  us  characterize  in  powerful 
ways  how  the  "engineering"  of  knowledge  might  rest  on  a  more  systematic 
understanding . 


2.  (X  IBS  ZD1A.  07  aOBLSDCS-BASBD  STSTSMS 


▲  historic  reminder  may  be  useful  to  clarify  the  term,  "knowledge-based. " 
This  phrase,  in  the  context  of  AI  systems,  arose  in  response  to  a  recognition, 
mainly  in  the  pioneering  work  of  Feigenbaum  and  his  associates  in  the  early  to 
mid-70's,  that  much  of  the  power  of  experts  in  problem  solving  in  their 
domains  arose  from  a  large  number  of  rule- like  pieces  of  domain  knowledge 
which  helped  constrain  the  problem  solving  effort  and  direct  it  towards 
potentially  uaeful  intermediate  hypotheses.  These  pieces  of  knowledge  were 
domain-specific  in  the  sense  that  they  were  not  couched  in  terms  of  general 
principles  or  heuristics  which  could  be  instantiated  within  each  domain,  but 
rather  were  directly  in  the  form*  of  appropriate  actions  to  try  in  various 
situations.  The  situations  corresponded  to  partial  descriptions  stated  in 
terma  of  domain  features  .  This  hypothesis  about  the  source  of  expert  problem 
solving  power  was  in  contrast  to  the  previous  emphasis  in  problem  solving 
research  on  powerful  general  principles  of  reasoning  which  would  work  on 
different  domain  representations  to  produce  solutions  for  each  domain.  Thus 
the  heuristic  of  the  General  Problem  Solver  program  (Newell  and 

Simon,  1972)  is  a  general  purpose  heuristic,  which  would  attempt  to  produce 
solutions  for  different  problems  by  working  on  the  respective  problem 
representations.  On  the  other  hand,  a  piece  of  knowledge  like,  "When 
considering  liver  diseases,  if  the  patient  has  been  exposed  to  certain 
chemicals,  consider  hepatitis,"  is  a  domain-specific  heuristic  which  the  human 
expert  was  said  to  use  directly. 

The  paradigm  for  knowledge-based  systems  that  was  elaborated  consisted  of 
extracting  from  the  human  experts  a  large  number  of  such  rules  for  each  domain 
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and  creating  a  knowledge-base  with  such  rules.  It  was  generally  assumed  as 
part  of  the  paradigm  that  the  rule-using  (i.e.,  reasoning)  machinery,  was  not 
the  source  of  problem  solving  power,  but  rather  the  rules  in  the  knowledge 
base.  Hence  the  slogan,  "In  Knowledge  Lies  the  Power." 

The  word  "knowledge"  in  "knowledge  base  systems"  is  used  in  a  rather 
special  sense.  It  is  meant  to  refer  to  the  knowledge  an  expert  problem  solver 
in  a  domain  was  posited  to  have  which  gives  a  great  deal  of  efficiency  to  the 
problem  solving  effort.  The  alternative  against  which  this  position  is  staked 
is  one  in  which  complex  problem  solving  machineries  are  posited  to  operate  on 
a  combination  of  basic  knowledge  that  defines  the  domain  with  various  forma  of 
general  and  common  sense  knowledge.  Thus  the  underlying  presu.se  behind  much 
of  the  AI  work  on  expert  systems  is  that  once  the  body  of  expertise  is  built 
up,  expert  reasoning  can  proceed  without  any  need  to  invoke  the  general  world 
and  common  sense  knowledge  structures.  If  such  a  decomposition  were  not  in 
principle  possible,  then  the  development  of  expert  systems  will  have  to  await 
the  solution  of  the  more  general  problem  of  cossson  sense  reasoning  and  general 
world  knowledge  structures.  What  portion  of  expert  problem  solving  in  a  given 
domain  can  be  captured  in  this  manner  is  an  empirical  question,  but  experience 
indicates  that  there  is  a  nontrivial  subset  of  expert  problem  solving  in 
important  domains  that  can  be  captured  in  this  manner.  This  decoupling  of 
common  sense  and  general  purpose  reasoning  from  domain  expertise  is  also  the 
explanation  for  the  rather  paradoxical  situation  in  AI  where  we  have  programs 
which  display,  e.g.,  expert- like  medical  diagnostic  capabilities  while  the 
field  is  still  some  distance  from  capturing  most  of  the  intellectual 
activities  that  children  do  with  ease. 

Wb  will  argue  later  in  the  paper  that  while  many  first  generation  expert 


9 


systems  have  been  ■accessful  in  relatively  simple  problems  with  this  approach 
which  lays  relatively  greater  emphasis  on  heuristic  knowledge  specific  to  the 
domain  at  the  expense  of  the  problem  solving  aspects,  the  next  generation  of 
research  in  this  area  as  veil  as  application  systems  —  will  be  bringing 
back  an  increased  emphasis  on  the  latter. 

3.  mm  unmicAL  to  sihbolzc  hosklzhg  or  szpsxusk 

In  this  section  ire  will  provide  two  sets  of  reasons  why  symbolic 
structures  become  necessary  to  support  decision-making.  By  conaidering  the 
example  of  multivariate  prediction,  we  will  suggest  that  certain  kinds  of 
computational  problems  are  alleviated  by  multiple-* level  symbolic  structures. 

In  the  next  subsection,  we  will  argue  that  certain  kinds  of  decisions  cannot 
be  made  purely  within  a  numerical  model  however  complete  it  may  be  in 
principle. 

3JL«  Bultivaxia&e  Clasaif ication 

There  ia  an  ubiquitous  but  conceptually  simple  class  of  problems  in 
decision-making  which  can  often  be  typically  modeled  as  mapping  a  multivariate 
state  vector  to  a  set  of  discrete  categorical  states.  The  classical  pattern 
classification  paradigm  deals  with  this  class  of  problems.  There  are  many 
application  domains  in  which  such  problems  arise  locally,  and  domain  experts 
may  be  called  upon  no  perform  such  a  classif icatory  task  as  part  of  a  larger 
problem-solving  effort.  Classifying  weather  conditions  based  on  a  number  of 
measurements  and  predicting  the  presence  or  absence  of  certain 
pathophysiological  conditions  on  the  basis  of  a  vector  of  numerical  predictor 
variables  are  examples  of  this  task.  Often,  once  the  predictor  variables 


themselves  are  chosen  in  consultation  with  the  experts,  and  when  the  state 
▼eetor  is  of  modest  dimensionality  (in  the  order  of  10's),  a  discriminant  type 
of  analysis  can  be  as  good  as  or  better  than  human  experts.  Much  theoretical 
effort  in  pattern  recognition  notwithstanding,  experience  in  this  type  of  task 
was  that  this  is  an  example  where  power  came  from  expert  choice  of  the 
variables,  rather  than  in  the  complexity  of  the  discriminants  themselves.  But 
when  the  dimensionality  of  the  state  vector  gets  very  large  this  approach  has 
serious  problems  both  in  ones  ability  to  compute  the  discriminant  as  well  as 
in  the  sensitivity  of  the  decision  to  small  changes.  Using  the  medical 
example  earlier,  the  totality  of  the  medical  diagnostic  problem  can  be 
formally  viewed  as  a  mapping  from  a  (very  large)  vector  of  manifestations  to  a 
(again  quite  large)  set  of  nsmed  diseases.  What  works  very  well  locally, 
i.e.,  for  state  vectors  of  low  dimensionality  and  few  decision  states, 
deteriorates  rapidly  when  the  sixes  get  large.  It  doesn't  matter  which  sort 
of  discriminant  one  uses:  statistical  ones  or  per ceptron- like  threshold 
devices.  The  computational  problems  in  the  statistical  case  are  described 
well  in  Ssolovits  and  Pauker  (1978).  Corresponding  difficulties,  especially 
those  relating  to  sensitivity  issues,  for  per  ceptronr- like  devices  are 
discussed  by  Minsky  and  Papert  01969). 

One  approach  to  overcoming  the  above  computational  problems  is  to 
introduce  multiple  levers  of  decisions.  Instead  of  one  classification 
function  from  say  a  200-dimensional  state  vector,  the  problem  can  be  broken 
into  groups  of  (possibly  overlapping)  state  vectors  of  the  order  of  10's,  each 
of  which  providing  a  small  number  of  discrete  values  as  local  mappings. 
Typically  these  groupings  will  correspond  to  potentially  meaningful 
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intermediate  entities,  so  that  one  can  interpret  each  grouping  as  computing  a 
symbolic  abstraction  corresponding  to  an  intermediate  concept.  At  the  second 
layer,  the  outputs  of  each  of  these  can  be  grouped  together  in  a  similar 
manner  and  the  process  repeated.  This  is  precisely  what  Signature  Tables  of 
Samuel  (1967),  did  in  transforming  a  description  of  a  checker  board 
configuration  into  a  classification  in  terms  how  good  the  board  was  for  a 
player.  Bach  stage  of  the  abstraction  is  computationally  simple.  An 
important  point  to  notice  is  that  a  shift  away  from  numerical  precision 
towards  discretization  and  symbolization  is  taking  place  here  in  capturing 
expertise . 


3 *2.  formal  Medela  ys  Symbolic  Knowledge  Structures 


Bren  if  one  had  a  complete  mathematical  model  of  a  situation,  that  by 
itself  is  not  often  sufficient  for  many  important  tasks.  All  the  numerical 
values  of  the  various  state  variables  will  still  need  to  be  interpreted. 
Identifying  interesting  and  potentially  significant  states  from  the  initial 
conditions  requires  qualitative  reasoning  rather  than  a  complete  mathematical 
simulation.  To  take  a  pedagogically  effective  but  fanciful  example,  consider 
a  household  robot  watching  its  master  carelessly  move  his  arm  towards  the  edge 
of  a  table  where  sits  a  glass  full  of  wine.  In  theory  a  complete  mathematical 
equation  of  the  arm  and  all  the  objects  in  the  room  including  the  volume  of 
wine  is  possible.  But  the  most  detailed  numerical  solution  of  this  will  still 
only  give  values  for  a  number  of  state  variables.  It  still  takes  further 
reasoning  to  interpret  this  series  of  values  and  arrive  at  a  simple  common 
sense  level  statement,  viz.,  "the  arm  will  hit  the  wine  glass  and  wine  will 


•pill  on  the  carpet.”  On  the  other  hand  the  aim  of  "naive  physics "  models  is 
to  support  qualitative  reasoning  that  can  arrive  at  such  conclusions  readily. 
The  reason  vhy  a  complete  numerical  solution  is  not  enough,  i.e.,  why  the 
above  symbolic  conclusion  ought  to  be  reached  by  the  robot  is  that  its  own 
knowledge  of  available  actions  is  more  appropriately  indexed  by  symbolic 
abstractions  as  "spilled  wine,”  rather  than  by  the  numerical  values  of  all 
ranges  of  relevant  state  variables  in  the  environment. 

Thus  when  faced  with  reasoning  tasks  involving  complex  systems,  both 
human  experts  as  well  as  expert  systems  are  necessarily  compelled  to  deal  with 
symbolic  knowledge  structures,  whether  or  not  complete  mathematical  models  may 
in  principle  be  available.  Human  experts  (as  well  as  AX  expert  systems)  may, 
at  specific  points  during  their  qualitative  reasoning,  switch  to  a  local 
formal  analysis,  such  as  a  medical  specialist  using  formulas  or  equations  to 
decide  which  side  of  the  acid/base  balance  a  patient  may  be  in,  but  this 
formal  analysis  is  at  the  overall  control,  of  a  symbolic  reasoning  system.  It 
is  the  symbolic  knowledge  and  problem  solving  structures  that  are  of  central 
interest  to  the  science  and  technology  of  AX. 

4«  QH  THS  SOU  OF  SOUS  XX  KBU-BASXD  STSTSHS 

As  anyone  with  even  a  cursory  knowledge  of  expert  systems  literature 
would  know,  the  most  dominant  form  of  symbolic  knowledge  in  the  first 
generation  of  expert  systems  has  been  rules.  In  our  view,  the  idea  of  rules 
as  a  formalism  for  encoding  knowledge  comes  from  at  least  three  distinct 
traditions,  and  a  failure  to  distinguish  between  the  different  senses  implied 
by  them  is  often  a  great  source  of  misunderstanding.  Let  us  list  the  three 


senses 


4.1.  Sals  Systems  as  "Universal"  Computing  Systi 


IC  is  well-known  Chat  Post  productions  as  veil  as  Markov  Algorithms,  both 
of  vhich  are  rule-based  formalisms  are  examples  of  universal  computation 
systems.  Any  computer  program,  including  an  expert  system,  can  be  encoded  in 
one  of  these  rule  systems  with  only  some  minimal  constraints  on  the 
interpreter.  In  this  sense  of  the  term,  the  rule-based  approach  becomes  a 
programming  technology.  Some  of  the  rules  in  almost  every  major  rule-based 
system  perform  such  a  purely  programming  role.  For  example,  rules  in  R1 
(McDermott,  1982)  which  set  contexts  can,  in  another  representation,  be  simply 
viewed  as  a  call  for  a  module  which  contains  a  block  of  knowledge  relevant  to 
that  context.  Metarules  (Davis,  1976)  can  also  be  viewed  as  attempts  to 
enable  the  specification  of  control  behavior  in  a  rule-based  programming 
system.  Hot  all  algorithms  can  be  equally  naturally  encoded  in  rule 
formalisms,  however.  Thus  often  expert  system  designers  wno  build  rule-based 
systems  complain  of  frustrations  they  face  when  they  have  to  come  up  with 
rules  to  make  the  system  have  good  control  behavior,  or  to  express  all  domain 
knowledge  in  rule  form;  i.e.,  they  are  not  encoding  "domain  knowledge"  aa  much 
«  doing  programming  ia  A 

Whether  the  rule-based  approach  is  a  good  programming  technology  for  an 
expert  task  depends  on  both  whether  the  necessary  control  behavior  as  well  as 
the  "facts  of  the  domain"  can  be  most  naturally  represented  in  rule  form.  In 
some  domains  there  is  a  202/ 801  effect  —  i.e.,  a  large  percentage  of  the 
domain  knowledge  may  appear  to  be  capturable  by  a  relatively  small  number  of 
rules,  but  a  rapid  growth  in  the  amber  of  rules  required  sets  in  if  one 
sttesq>ts  to  capture  more  and  more  of  the  domain  knowledge  (McDermott,  1982). 
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4*2.  Sales  ss  in  "Bules-of-Thamb " 

The  coMon  sense  notion  of  rules  is  one  of  an  approximate,  quick  guide  to 
action,  a  computationally  leas  expensive  alternative  to  real  thinking, 
adequate  for  most  occasions,  but  still  vith  potential  pitfalls.  4  related 
notion  is  that  of  a  rule  as  something  that  captures  a  relationship  which  is 
only  statistically  valid,  or  a  relationship  whose  causal  antecedents  are 
poorly  understood.  Buies  in  medical  diagnosis  systems  of  the  form,  "If  male 
and  findings  x,  y,  z,  assign  k  units  of  evidence  to  hypothesis  H,"  are  of  this 
type,  where  some  statistical  differential  between  the  sexes  in  the  likelihood 
of  having  a  certain  disease  might  be  used. 

This  sense  of  rules  is  often  the  basis  of  concerns  that  rule-based 
approaches  are  "shallow"  and  for  hard  problems  "causal"  models  are  needed. 

It  ought  to  be  emphasized  that,  this  common  sense  notion  notwithstanding, 
the  fact  that  an  expert  system  is  rule-based  should  not  necessarily  imply  that 
it  is  engaged  in  shallow  reasoning;  or  that  it  is  using  knowledge  of  only 
approximate  validity.  For  example,  &1  uses  rules  which  are  perfectly  sound 
pieces  of  knowledge  shout  the  domain  of  computer  system  configuration.  To  the 
extent  that  any  computer  program  can  be  written  in  a  rule-based  computational 
framework,  the  shallow  vs.  deep  characterization  does  not  arise  from  its  rule 
form,  but  from  the  character  of  the  rules. 


4*3*  Kales  as  Cognitive  Units 


The  third  stream  of  ideas  relating  to  the  prominence  of  rules  in  expert 
systems  is  the  ides,  due  to  Newell  (1983) ,  of  rules  as  the  basic  form  of  knowledge 
formation  in  the  human  short-term  memory.  In  this  theory  rules  become  the 
basic  building  blocks  of  human  knowledge  structures.  This  sense  of  rules 
gives  rule-based  systems  an  aura  of  legitimacy  as  models  of  intelligence.  But 
we  feel  that  one  should  be  very  cautious  about  making  this  connection,  even 
though  it  seems  a  natural  one  in  the  light  of  the  fact  that  expert  systems  are 
a  branch  of  artificial  intelligence.  This  interpretation  is  neither  necessary 
nor  sufficient  for  the  role  of  rules  in  expert  systems.  It  is  not  necessary 
because,  while  41  programs  may  advantageously  model  human  thought  at  some 
level  of  abstraction,  it  is  not  obvious  that  it  should  do  so  at  the  level  of 
knowledge  formation  in  short-term  memory,  especially  for  capturing  expert 
problem-solving  performance.  It  is  not  sufficient  because  even  if  rules  were 
the  basic  units  of  cognition,  a  number  of  further  constructs  are  needed  to 
account  for  their  organisation  into  higher  level  units  such  as  concepts,  and 
for  their  interaction  with  problem  solving. 

4«4«  Shea  Axe  Bale-Based  Systems  Appropriate l 

The  term  "rule-based  system"  has  coqe  to  mean  an  expert  system  which  has 
a  knowledge  base  of  rules  and  a  problem  solver  —  such  as  a  forward-chaining 
system  or  a  backward-chaining  system,  or  a  production  system  controller  such 
as  0P35  (Forgy  &  McDermott,  1977)  —  that  uses  the  knowledge  base  to  make 
inferences.  It  is  conceptually  important  to  keep  in  mind  that  the  use  of 
rules  as  a  representation  device  does  not  necessarily  force  one  to  use  the 
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rule-based  system  architecture  mentioned  above,  i.e.,  rules  can  be  used  for 


expert  system  design  in  significantly  different  architectures.  MDX 
(Chandrasekaran  &  Mittal,  1983),  e.g.,  has  some  of  its  medical  knowledge  in 
the  form  of  rules,  but  it  is  organized  as  a  hierarchical  collection  of 
"specialists.1*  We  shall  discuss  this  system  later  in  the  paper.  The  remarks 
that  follow  apply  to  the  use  of  rules  in  the  standard  rule-based  system 
architectures . 

Because  the  problem  solver  (or,  the  inference  engine,  as  it  has  come  to 
be  called)  is  itself  free  of  knowledge,  controlling  the  problem  solving 
process  often  involves  placing  more  or  less  complex  rules  for  control  purposes 
in  the  knowledge  base  itself.  This  is  the  "programming  technology"  sense  of 


the  use  of  rule  based  systems  that  was  mentioned  earlier.  Normally,  the 
rule-based  architecture  mentioned  above  works  quite  well  when  relatively 
little  complex  counting  between  rules  exists  In  solving  problems,  or  the  rules 
can  be  implicitly  chunked  into  groups  with  little  local  interaction  between 
rules  in  different  chunks.  R1  is  an  example  where  there  is  a  virtual  chunking 
of  rules  for  subtasks,  and  the.  reasoning  proceeds  in  a  relatively  direct  and 
focused  way.  In  general,  however,  when  the  global  reasoning  requirements  of 
the  task  cannot  be  conceptualised  as  a  series  of  linear  local  decisions,  the 


rule-based  systems  of  the  simple  architecture'  results  in  significant  "focus" 


problems,  i.e.,  since  the  problem  solver  does  not  have  a  notion  of  purposes  at 
different  levels  of  abstraction,  there  are  often  problems  in  maintaining 


coherent  lines  of  thought.  Focus  needs  maintenance  of  multiple  layers  of 
contexts,  goals  and  plans.  We  shall  discuss  later  how  alternative 
architectures  may  be  conceived  for  better  focus  in  problem  solving.  These 
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architectures  will  begin  to  erase  the  separation  of  knowledge  base  from  the 
inference  machinery* 

There  is  one  pragmatic  aspect  of  rule-based  approaches  to  expert  system 
design  that  is  important.  Since  only  certain  kinds  of  expertise  have  natural 
expression  as  rules,  a  rule-based  approach  may  encourage  a  false  feeling  of 
security  in  capturing  expertise.  The  human  expert  often  may  not  bring  up 
expertise  hard  to  express  in  that  form.  The  20Z/80Z  phenomenon  is  vorth 
recalling  here:  i.e.,  as  the  most  rule-like  pieces  of  knowledge  get  encoded, 
there  may  be  an  acceptable  initial  performance,  but  as  more  knowledge  that  is 
not  naturally  rule- like  is  being  acquired,  the  size  of  the  rule  base  may  grow 
very  rapidly.  N 

5.  on  logic  in  nuns  is  uraxsnxmoi  yoransns 

The  architecture  of  systaas  using  some  sort  of  a  logical  formalism  for 
knowledge  representation  is  generally  similar  to  that  of  the  rule-based 
systems  discussed  earlier.  That  is,  there  are  a  knowledge  base  of  formulas  in 
some  logical  formalism,  and  an  inference  machinery  that  uses  the  formulas  to 
make  further  inferences.  But  since  there  are  several  forms  of  logic  with 
well-understood  semantics  —  unlike,  say,  production  rules  —  logic  enjoys  a 
status  as  theoretically  more  rigorous  for  knowledge  representation  purposes. 

In  practical  terms,  however,  the  existence  of  rigorous  semantics  is  not  always 
helpful,  since  the  semantics  are  often  not  at  the  right  level  of  abstraction; 
e.g.,  it  is  often  difficult  to  incorporate  context-dependent  inference 
strategies  in  logic-based  systems.  If  one  were  to  model,  say,  reasoning  in 
arithmetic,  one  could  represent  domain  knowledge  in  the  form  of  axioms,  and 
use  a  variety  of  inference  machineries  to  derive  new  theorens .  However,  the 
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computational  coup laxity  of  such  systems  tends  to  be  impractical  even  for 
relatively  simple  axiomatic  systems.  Even  in  such  domains  where  in  theory 
powerful  axiom  systems  exist,  capturing  the  effectiveness  of  human  reasoning 
is  an  open  research  area.  On  the  other  hand,  in  tasks  where  the  inference 
chains  are  relatively  shallow,  i.e,  the  discovery  of  the  solution  does  not 
involve  search  in  a  large  apace,  the  logic  representation  may  be  more 
practical.  Analogous  to  our  remarks  regarding  the  appropriateness  of 
rule-based  sy steam  when  there  is  an  implicit  structure  to  the  task  that  can  be 
mapped  into  chunking  of  rules,  in  logic-based  systems  also  it  is  possible  to 
create  a  similar  subtasking  structure  that  can  keep  the  complexity  of 
inference  low. 

To  our  mind,  both  the  logic-based  architectures  and  the  rule-based 
architectures  have  surprising  similarities  in  some  dimensions;  in  both  of 
them,  the  architecture  separates  a  knowledge  base  from  mechanisms  that  use  the 
knowledge.  In  both  eases,  this  results  in  an  increasing  need  to  place  in  the 
knowledge  base  more  and  more  control-type  knowledge  —  the  representations 
increasingly  become  programming  technologies  rather  than,  perspicuous  encodings 
of  problem  solving  activity.  Because  of  an  inability  at  that  level  to  specify 
coaq>lex  structures  such  as  contexts  and  goal  hierarchies,  the  approaches  are 
subject  to  problems  of  focus  in  reasoning. 

Control  of  problem  solving  requires,  in  our  opinion,  organising  knowledge 
into  chunks,  and  invoking  portions  of  the  knowledge  structures  and  operating 
on  them  in  a  flexible,  context-dependent  manner.  The  knowledge  representation 
approach  in  AI  that  first  emphasised  organisation  in  the  form  of  structured 
units  was  that  of  (Minsky,  1975).  Frames  are  especially  useful  in 

organising  a  problem  solver's  "what"  knowledge—  knowledge  about  objects. 
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e.g.  —  in  such  a  way  Chat  efficiency  in  scorage  as  veil  as  inference  can  be 
maintained.  Assuming  some  familiarity  on  the  part  of  the  reader  vith  the 
frame  concept,  ve  vill  briefly  mention  three  aspects  of  frames  that  contribute 
to  this  efficiency.  Basically,  a  frame  of  a  concept  being  a  structured 
stereotype,  much  of  the  knowledge  can  be  stored  as  "defaults,"  and  only  the 
information  corresponding  to  differences  from  the  default  value  needs  to  be 
explicitly  stored.  For  example,  the  default  value  of  the  number  of  vails  for 
a  room  is  4,  the  knowledge  of  the  system  about  a  particular  room  does  not  have 
to  explicitly  store  this,  unless  it  is  an  exception,  e.g.,  it  is  a  5— walled 
room. 

A  second  benefit  of  organizing  one's  knowledge  of  objects  in  the  form  of 
frame  structures  is  that  one  can  create  frame  hierarchies,  and  let  much  of  the 
knowledge  about  particular  objects  be  inherited  from  information  stored  at  the 
class  level.  This  again  makes  for  great  economy  of  storage.  For  instance, 
the  "purpose"  slots  of  a  bedroom  and  a  living  room  may  be  different,  but  the 
parts  that  are  common  to  them,  e.g.,  typically  all  rooms  have  four  walls,  a 
ceiling  etc.,  can  be  stored  at  the  level  of  the  "room”  frame,  and  inherited  as 
needed  at  the  "bedroom”  or  "living  room"  level. 

A  third  mechanism  that  makes  frame  structures  very  useful  H  expert 
systems  is  the  possibility  of  embedding  procedures  in  the  frames  so  that 
certain  inferences  can  be  performed  as  appropriate  for  the  conceptual  context. 
This,  as  can  be  seen,  is  a  move  away  from  the  rule-based  system  architecture, 
where  the  inference  mechanisms  were  divorced  from  the  knowledge  base. 

Because  of  these  three  properties,  frame  systems  are  very  useful  for 
capturing  one  broad  class  of  problem  solving  activity,  viz.,  one  where  the 
basic  task  can  be  formulated  as  one  of  siting  inferences  about  objects  bv 
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wiat  smIl  taaaltd&ft  at  fisted  object*  elsewhere  ia  un. « tractor*.  Thu*  « 
whole  class  of  programing  styles  called  "object-oriented"  programing  baa 
ariaen  which  has  conceptual  kinship  with  the  notion  of  frame* . 

i.  OtCAITZlTTQB  OF  aOILKDa 

Been  though  many  know ledge-baa e  system*  follow  the  popular  architecture 
of  a  knowledge  base  (generally  of  rales,  but  many  times  of  other  forms: 
networks  in  Prospector,  frames  in  Pip)  and  an  inference  engine,  often  they 
here  further  internal  architectures,  but  which  are  implicit  in  the  sense  that 
they  are  accomplished,  as  mentioned  in  an  earlier  section,  by  using 
programming  techniques  (again,  typically  using  rules  to  specify  conditions  for 
transfer  to  the  module)  to  achieve  some  degree  of  modularisation  of  the 
knowledge  into  groups.  Before  we  discuss  this,  however,  some  account  of  the 
need  for  this  sort  of  organisation  is  called  for. 

When  the  number  of  doeusin  rules  in  the  knowledge  base  is  large,  typically 
several  rules  will  "fire,"  i.e.,  their  left  hand  sides  will  natch  the  state  of 
the  data*  Since  the  inference  machinery  (because  in  the  standard  architecture 
it  is  deliberately  kept  domain-independent)  does  not  have  the  domain  knowledge 
to  choose  among  them,  either  some  sort  of  syntactic  conflict-resolution 
mechanisms  need  to  be  used  (such  as  the  technique  of  &1  which  chooses  that 
rule  whose  conditions  strictly  subsume  those  of  s  contending  rule),  or  all  of 
them  will  need  to  be  tried.  The  latter  option  has  the  potential  for 
combinatorial  explosion.  Most  systems  attempt  to  cope  with  this  problem  by 

3 We  will  argue  in  See.  7  against  this  separation  but  for  our  immediate 
purposes  that  is  not  important. 


creating  "contexts,"  which  help  specify  a  small  set  of  rales  in  the  base  as 
candidates  to  be  considered  for  watching.  For  example,  each  sobtask  in  &1 
creates  a  context  and  only  mlea  relevant  to  that  sobtask  are  considered  for 
watching.  This  technique  essentially  decowposes  the  rule  base  (except  for  the 
roles  which  effectuate  the  transfer  froa  module  to  wodule)  into  a  number  of 
virtual  modules,  each  for  a  subtask.  Prospector  (which  is  a  geological 
consultation  system,  (Duda  et  al,  1979)),  while  not  a  rule-based  system 
explicitly,4  also  organises  its  knowledge  in  the  form  of  ’^eodels,"  each  model 
corresponding  to  a  classification  hypothesis  about  the  geological  make-up.  In 
sense,  each  nodal  is  a  "specialist"  in  that  hypothesis.  Metarules  (Davis, 

1976)  have  been  proposed  as  a  special  class  of  rules  to  embody  "control 
knowledge."  These  also  play  the  role  of  decomposing  the  knowledge  base  into 
portions  that  are  relevant  for  classes  of  situations.  Without  some  such 
attempt  at  organisation,  the  problem  solving  process  will  be  generally  be  very 
fflBfMMIld-  serious  control  problems  will  arise. 

▲11  the  above  organisational  devices  were  i— »«»«;,.  and  are  subject  to 
the  constraints  of  the  rule  formalism  on  the  one  hand,  and  the  uniformity  of 
the  inference  procedure  on  the  other.  The  uniformity  of  the  inference 
machinery  makes  it  difficult  to  arrange  for  different  subtasks  during 
reasoning  to  exploit  different  ways  of  going  about  using  the  knowledge.  Again 
it  is  worth  emphasising  that  the  issue  is  not  one  of  the  computational 
sufficiency  of  the  rule  mechanism,  but  one  of  naturalness  and  conceptual 
adequacy. 

4 but  the  content  of  the  network  representation  can  be  translated  into  rule 
forms  in  a  straightforward  way 


Our  own  work  (e.g,  (Chandrasekaran,  1983),  which  gives  an  overview  of  our 
activity)  has  been  directed  toward  the  development  of  a  theoretical  basis  of 
knowledge  organisation  for  expert  problem  solving.  Ve  will  outline  some 
aspects  of  this  theory  in  the  next  section. 

7*  carcxra  id  pmuK  sqltug  tots  is  obcaitt.  attotal  cobstsdces 

To  restate  a  point  from  the  last  section:  Even  the  implicit 
modularization  of  the  knowledge  base  due  to  various  context-setting  mechanisms 
is  not  always  sufficient  when  the  task  domain  consists  of  subtasks  which  might 
differ  from  each  other  in  the  nature  of  the  problem  solving,  i.e.,  the  use  of 
knowledge  that  is  required  for  that  subtask.  The  work  to  be  discussed  has 
been  directed  toward  elaborating  a  framework  in  which  different  generic  types 
of  probled  solving  can  be  related  to  the  types  of  knowledge  organizations 
required  for  them. 

7*1*  Generic  Tasks 

The  theory  proposes  that  there  are  well-defined  generic  tasks  each  of 
which  calls  for  a  certain  organizational  and  problem  solving  structure.  We 
have  identified  several  such  generic  tasks  from  our  work  in  the  domains  of 
medicine  and  reasoning  about  engineered  systems. 

The  classifies tony  task  that  is  at  the  core  of  medical  diagnosis,  i.e., 
the  task  which  classifies  a  complex  ease  description  as  a  node  in  the  disease 
hierarchy  is  an  example  of  such  a  generic  task.  It  is  generic  because  it  is  a 
component  of  many  real  world  problem  solving  situations.  For  example,  a 
tax-advising  expert  program  might  go  through  a  stage  of  classifying  the  user 
as  a  particular  type  of  taxpayer  before  invoking  strategies  that  may  be 


appropriate  for  that  elaas  of  taxpayer.  We  have  already  diacuseed  in  See.  3 
simpler  versions  of  thia  task.  The  problem  solving  for  this  task,  as 
implemented  in  our  aadieal  diagnosis  system,  MDX,  vill  be  considered  in  Sec. 

7.  1.  1. 

Another  example  of  a  generic  task  is  what  ve  call  a  WWHI-type  (for  "What 
Will  Happen  If")  reasoning  which  attempts  to  derive  the  consequences  of  an 
action  that  might  be  taken  on  a  complex  system.  Such  a  task  is  useful  as  a 
subtask  in  an  expert  system  that  trouble-shoots  and  repairs  a  complex  system 
whare  it  may  be  useful  to  reason  out  the  consequences  of  a  proposed  corrective 
action. 

A  third  type  is  a  form  of  knowledge-directed  associative  memory  that 
helps  retrieve  information  by  reasoning  about  other  related  information;  ve 
have  uaed  this  type  of  problem  solving  in  an  intelligent  data  base  system, 
PAXIKC  (Mittal  and  Chandrasekaran,  1980).  A  fourth  type  is  a  form  of  plan 
synthesis,  which  ve  are  using  to  build  an  expert  system  for  mechanical  design 
(Brown  and  Chandrasekaran,  1983).  It  is  clsar  that  there  are  many  more  such 
generic  tasks,  and  it  is  part  of  our  research  program  to  identify  more  of 
them. 

An  iiwirtent  cnnaeanwnce  of  identifying  such  tasks  U  that  it  gives  US  A 
framework  to  the  capabilities  of  expert  izilttl.*  U  *  real  world 

task  can  be  decomposed  into  a  nmsber  of  generic  tasks  for  each  of  which  we 
know  how  to  build  a  reasoning  system,  then  there  vill  be  a  basis  for 
concluding  that  the  task  domain  can  be  successfully  tackled  by  an  expert  system. 

In  the  next  two  subsections,  ve  vill  discuss  in  greater  detail,  but  still 
in  schematic  terms,  how  knowledge  can  be  organized  and  problem  solving  can  be 
accomplished  for  two  of  the  above  generic  tasks.  Cited  references  can  be 


consulted  both  for  aoro  details  on  theao  tasks,  as  well  as  for  information  on 
ths  other  two  problem  so lying  types  that  we  omit  here  due  to  space 
limitations . 

7.1.1.  The  Classificatory  Task 

As  mentioned  earlier,  the  task  is  the  identification  of  a  case 
description  with  a  specific  node  in  a  pre-determined  diagnostic  hierarchy, 
for  the  purpose  of  current  discussion  let  us  assume  that  all  the  data  that  can 
be  obtained  are  already  there,  i.e.,  the  additional  problem  of  launching 
exploratory  procedures  such  as  ordering  new  tests  etc.  does  not  exist.  The 
following  brief  account  is  a  sassary  of  the  more  detailed  account  given  in 
Comes  and  Chandrasekaran  (1981)  of  diagnostic  problem-solving. 

Let  us  imagine  that  corresponding  to  each  node  of  the  classification 
hierarchy  alluded  to  earlier  we  identify  a  "concept."  The  total  diagnostic 
knowledge  is  then  distributed  through  the  conceptual  nodes  of  the  hierarchy  in 
a  specific  manner  to  be  discussed  shortly.  The  problcm-so lying  for  this  task 
will  be  perfonsed  top  down,  i.e.,  the  top-most  concept  will  first  get  control 
of  the  case,  then  control  will  pass  to  an  appropriate  successor  concept,  and 
so  on.  In  the  medical  example,  a  fragment  of.  such  a  hierarchy  might  be  as 
shown  in  figure  1. 
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Figure  1.  Fragment  of  a  classificatory  hierarchy 


Mora  general  elassif icatory  concepts  are  higher  in  the  structure,  while  aore 
particular  ones  are  lower  in  the  hierarchy.  It  is  as  if  URZBHIST  first 
establishes  that  there  is  in  fact  a  disease,  then  LIVER  establishes  that  the 
case  at  hand  is  a  liver  diseaae,  while  say  HEART  etc.  reject  the  case  as  being 
not  in  their  doaain.  After  this  level,  JADED ICE  My  establish  itself  and  so 
on. 

_ • 

The  prob lee-solving  that  goes  on  in  such  a  structure  is  distributed.  The 
problem-solving  regime  that  is  implicit  in  the  structure  can  be  characterized 
as  an  "as tab lish- vf  ina"  type.  That  is,  each  concept  first  tries  to  establish 
or  reject  itself.  If  it  succeeds  in  establishing  itself,  the  refinement 
process  consists  of  seeing  which  of  its  successors  can  establish  itself.  The 
way  in  which  each  concept  (or  "specialist1*)  attempts  to  do  the 
establish-ref ine  reasoning  nay  vary  from  domain  to  domain.  In  medicine  it  nay 
often  be  accomplished  by  using  knowledge  in  the  form  of  a  collection  of  rules, 
some  of  which  look  for  evidence  for  the  hypothesis,  some  for  counter  evidence, 
and  others  which  carry  information  about  how  to  combine  then  for  a  final 
conclusion.  In  reasoning  about  electrical  circuits  on  the  other  hand  it  nay 
be  more  appropriate  to  represent  the  establish-ref ine  activity  in  the  form  of 


functional  knowledge  about  specific  modules.  (That  is,  performance  of  a 
generic  task  may  require  solution  of  some  problem  of  a  different  type  as  a 
subtask.) 

In  our  medical  diagnosis  system  MDX,  each  of  the  concepts  in  the 
classification  hierarchy  has  "how-to"  knowledge  in  it  in  the  form  of  a 
collection  of  diagnostic  rules.  These  rules  are  of  the  form:  <symptoms> 

<concept  in  hierarehy>,  e.g.,  "If  high  SGOT,  add  n  units  of  evidence  in 
favor  of  cholestasis."  Because  of  the  fact  that  when  a  concept  rules  itself 
out  from  relevance  to  a  ease,  all  its  successors  also  get  ruled  out,  large 
portions  of  the  diagnostic  knowledge  structure  never  get  exercised.  On  the 
other  hand,  when  a  concept  is  properly  invoked,  a  small,  highly  relevant  set 
of  rules  comes  into  play. 

Bach  concept,  as  mentioned,  has  several  clusters  of  rules:  confirmatory 
rules,  exclusionary  rules,  and  perhaps  some  recommendation  rules.  The 
evidence  for  confirmation  and  exclusion  can  be  suitably  weighted  and  combined 
to  arrive  at  a  conclusion  to  establish,  reject  or  suspend  it.  The  last 
mentioned  situation  may  arise  if  there  is  not  sufficient  data  to  make  a 
decision.  Barf andation  rules  are  further  optimisation  devices  to  reduce  the 
work  of  the  subconcepts.  Further  discussion  of  this  type  of  rules  is  not 
necessary  for  our  current  purpose. 

The  concepts  in  the  hierarchy  are  clearly  not  a  static  collection  of 
knowledge.  They  are  active  in  problem-solving .  They  also  have  knowledge  only 
about  establishing  or  rejecting  the  relevance  of  that  conceptual  entity.  Thus 
they  may  be  termed  "specialists,"  in  particular,  "diagnostic  specialists."  The 
entire  collection  of  specialists  engages  in  distributed  problem-solving. 

The  above  aeeount  of  diagnostic  problea^solving  is  quite  incomplete.  We 


have  not  indicated  how  Multiple  diaaaaas  can  ba  handled  within  the  framework 
chore,  in  particular  when  a  patient  haa  a  dieeaac  secondary  to  another 
disease.  Go* ex  has  developed  a  theory  of  diagnostic  problem-solving  which 
enables  the  specialists  in  the  diagnostic  hierarchy  to  communicate  the  results 
of  their  analysis  to  each  other  by  means  of  a  blackboard  and  how  the 
problem-solving  by  different  specialists  can  be  coordinated.  Similarly,  how 
the  specialists  combine  the  uncertainties  of  nodical  data  and  diagnostic 
knowledge  to  arrive  at  a  relatively  robust  conclusion  about  establishing  or 
rejecting  a  concept  is  an  important  issue,  for  a  discussion  of  which  we  refer 
the  reader  to  Chandr aaekar an ,  Mittal  and  Smith  (1982). 

The  points  to  notice  here  are  the  following.  The  inference  engine  is 
tuned  for  the  elasaifieatory  task,  and  the  control  transfer  from  specialist  to 
specialist  is  implicit  in  the  hierarchical  conceptual  structure  itself.  One 
could  view  the  inference  machinery  aa  "embedded"  in  each  of  the  concepts 
directly,  thus  giving  the  sense  that  the  concepts  are  "specialists." 

7.1.2.  What- Wi  1 1-Haouen- If  (WWHI)  or  Consequence  Finding 

■samples  of  this  type  of  reasoning  sre:  "What  will  happen  if  valve  A.  is 
closed  in  this  power  plant  whan  the  boiler  is  under  high  pressure?";  "What 
will  happen  if  drug  ▲  is  administered  when  both  hepatitis  and  arthritis  are 
known  to  be  present?”  Questions  such  as  this  can  be  surprisingly  complex  to 
answer  since  formally  it  involves  tracing  a  path  in  a  potentially  large  state 
space.  Of  course  what  makes  it  possible  in  practice  to  trace  this  path  is 
domain  knowledge  which  constrains  the  possibilities  in  an  efficient  way. 

The  problem-solving  involved,  and  correspondingly  the  use  of  knowledge  in 


this  process,  are  different  from  that  of  diagnosis.  For  one  thing,  many  of 


thm  pieces  of  know ledge  for  Che  tvo  teaks  ere  completely  different*  For 
example,  consider  answering  the  question  in  the  automobile  mechanic's  domain: 
"Vhat  will  happen  if  the  engine  gets  hot?”  Looking  at  all  the  diagnostic  rules 

of  the  form,  "hot  engine  - >  <aalfunction>"  will  not  be  adequate,  since 

<malfuaction>  in  the  above  rules  is  the  cause  of  the  hot  engine,  while  the 
consequence  finding  process  looks  for  the  effects  of  the  hot  engine. 

Formally,  if  we  regard  the  underlying  knowledge  as  a  network  connected  by 
cause-effect  links,  where  from  each  node  multiple  cause  links  as  well  as 
effect  links  emanate,  we  see  that  the  search  processes  are  different  in  the 
two  instances  of  diagnosis  and  consequence-finding*  The  diagnostic  concepts 
that  typically  help  to  provide  focus  and  constrain  search  in  the  pursuit  of 
correct  causes  will  thus  be  different  from  the  WWH1  concepts  needed  for  the 
pursuit  of  correct  effects. 

The  embedded  problem-solving  is  also  correspondingly  different.  Ve 
propose  that  the  appropriate  language  in  which  to  express  the 
consequence-finding  rules  is  in  terms  of  stato-ch*n*ea-  To  elaborate: 

-  1.  mil-condition  is  first  understood  as  a  state  change  in  a 
subsystem. 

-  2.  Bales  ere  available  which  have  the  form  ”<state  change  in 
eubsystem>  will  result  in  <atate  change  in  subsystem>”.  Just  as  in 
the  case  of  the  diagnosis  problem,  there  are  thousands  of  rules  in 
the  case  of  any  nontrivial  domain.  Again,  following  the  diagnostic 
paradigm  we  have  already  set,  ve  propose  that  these  rules  be 
associated  with  conceptual  specialists.  Thus  typically  all  the 
state  change  rules  whose  left  hand  side  deals  with  a  subsystem  will 
be  aggregated  in  the  specialist  for  that  subsystem,  and  the  right 


hand  aid*  of  those  rules  will  refer  Co  the  state  changes  of  the 
iWtllilttlT  affected  systems. 

Again  we  propose  that  typically  the  specialists  be  organized 
hierarchically,  so  that  a  subsystem  specialist,  given  a  state  change  to  it, 
determines  by  knowledge-based  reasoning  the  state  changes  of  the  inswdiately 
larger  system  of  which  it  is  a  part  and  calls  that  specialist  with  the 
information  determined  by  it.  This  process  will  be  repeated  until  the  state 
change(s)  for  the  overall  system,  i.e.,  at  the  most  general  relevant  level  of 
abstraction,  are  determined.  This  form  of  organization  of  the  rules  should 
provide  a  great  deal  of  focus  to  the  reasoning  process. 


An  Illustrative  Example. 

Consider  the  question,  in  the  domain  of  automobile  mechanics,  "WWHI  there 
is  a  leak  in  the  radiator  when  the  engine  is  running?"  We  suggest  the 
specialists  are  to  be  organised  as  in  Figure  2  : 
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Figure  2.  Example  of  W  J  concept  hierarchy 


The  internal  states  that  the  radiator  fluid  subsystem  night  recognise  may  be 
partially  listed  as  follows:  {leaks /no  leaks,  rust  build-up,  total  mount  of 
water,...  };  similarly,  the  fan  subsystem  specialist  might  recognize  states 
{bent/straight  fan  blades,  loose/tight/disconnected  fan  belt, ...}•  The 
jSgStUggg  sts tan  subsTstem  itself  need  not  recognize  states  to  this  degree  of 
detail;  being  a  specialist  at  a  somewhat  higher  lewel  of  abstraction  it  will 
recognise  states  such  as  {fluid  flow  rate,  cooling-air  flow  rate.. .etc.}.  Let 
us  say  that  the  radiator  fluid  specialist  has,  smong  others,  the  following 
rules.  The  rules  are  typically  of  the  form: 

<internal  state  change>  - >  <supersystsm  state  change> 

leak  in  the  radiator  — — >  reduced  fluid  flow-rats 

high  rust  in  the  pipes  — — >  reduced  fluid  flowrate 

no  antifreeze  in  the  water  and  very  cold  weather  —  >  zero  fluid 
flow  etc. 


The  cooling  system  specialist  might  have  rules  o£  the  form: 

low  fluid-flow  rate  and  engine  running  ■-— >  engine  state  hot 
low  air— flow  rate  and  engine  running  — — >  engine  state  hot 

Again  note  that  the  internal  state  recognition  is  at  the  appropriate  level  of 
abstraction,  and  the  conclusions  refer  to  state  changes  of  its  parent  system. 

It  should  be  fairly  clear  hov  such  a  system  might  be  able  to  respond  to 
the  query  about  radiator  leak.  Again  a  blackboard  for  this  task  would  make  it 
possible  to  take  into  account  subsystem  interaction. 

Unlike  the  structures  for  the  diagnostic  and  data  retrieval  tasks,  we 
have  not  yet  implemented  a  system  performing  the  WWHI-task.  While  we  cannot 
speak  with  assurance  about  the  adequacy  of  the  proposed  solution,  we  feel  that 
it  is  of  a  piece  with  the  other  systems  in  pointing  to  the  same  set  of  morals: 
embedding  still  another  type  of  problem-solving  in  a  knowledge  structure, 
which  consists  of  cooperating  specialists  of  the  same  problem-solving  type.  . 

7«2«  Discussion 

Since  each  of  the  generic  tasks  involves  a  problem-solving  behavior  which 
is  unique  to  that  task,  the  standard  architecture  of  a  knowledge  base  and  a 
general  purpose  inference  machinery  is  not  applicable  here.  There  is  a  closer 
intertwining  of  knowledge  structures  and  corresponding  inference  methods.  At 
the  implementation  level,  one  can  view  the  system  as  being  decomposed  into  a 
collection  of  pairs  of  the  form  (<knowledge  structure,  inference  method>), 
indexed  by  the  generic  tasks,  e.g.,  diagnostic  structure,  establish-ref ine>. 
However  it  is  conceptually  more  appropriate  to  view  each  of  the  specialists  as 
having  the  inference  machinery  "embedded"  in  them.  This  interpretation  gives 


Che  term  "specialises"  aa  added  degree  o£  aptness. 

In  Sec.  2  ve  mentioned  that  the  £irst  generation  o£  expert  systems 

emphasised  the  power  of  knowledge  itself  over  that  of  the  problem  solving  method. 
In  the  current  section  we  have  attempted  to  restore  the  balance,  by  showing 
how  a  variety  of  problem-solving  types  in  conjunction  with  appropriate 
organizations  of  knowledge  can  solve  a  greater  variety  of  problems. 

a.  nnn  systems  that  hhpustap 

Ve  have  outlined  an  evolution  of  expert  systems  from  collection  of  rules 
to  cooperative  problem  solving  by  a  community  of  specialists  in  different 
kinds  of  problem  solving.  The  knowledge  that  is  in  each  of  the  specialists, 
e.g.,  the  diagnostic  rules  in  the  dassifieatory  specialists  or  the  state 
abstraction  rules  in  the  WEI  specialists  in  the  previous  section,  is  itself 
"compiled.1*  This  knowledge  is  obtained  from  human  experts  who  either  learnt 
that  knowledge  originally  in  that  compiled  form,  formed  it  as  a  result  of 
experience,  or  derived  it  from  a  deeper  model  of  the  domain.  In 
Chandrasekaran  and  Mittal  (1982)  we  argue  that  in  principle,  given  any  deep 
model  of  the  doauun,  css  can  compile  an  MDX-like  diagnostic  system  which  is  as 
powerful  as  the  deeper  model,  but  more  efficient  than  it,  for  the  diagnostic 
problem.  However,  in  practice,  the  compiled  structures  are  likely  to  remain 
for  various  reasons,  and  it  would  be  very  attractive  to  endow 
expert  systems  with  deeper  understanding  of  their  domains  to  protect 
themselves  against  incompleteness. 


Attempts  to  give  expert  systems  some  ability  to  do  deeper  level  reasoning 
have  typically  taken  the  direction  of  giving  the  system  a  mechanism  to  reason 
at  more  or  less  levels  of  detail  by  using  a  prestored  knowledge  base  of  causal 


associations.  In  CASKET  (Weiss,  at  al.,  1978)  an  attempt  is  mads  to  trace  out 
the  most  likely  causal  sequence  given  some  likely  intermediate  states  for 
which  there  is  evidence  and  some  states  which  can  be  assumed  not  to  have 
occurred.  A  knowledge  base  of  possible  esusal  connections  between  states  with 
associated  likelihood  information  is  used  to  fit  a  most  likely  path  that  goes 
through  the  states  for  which  there  is  evidence  and  avoids  the  unlikely  states. 
ABEL  (Patil,  1981)  uses  causal  association  information  at  different  levels  of 
detail.  There  may  be  a  piece  of  knowledge  at  the  top  level  of  the  form,  "A 
causes  B,"  but  at  a  more  detailed  level,  there  may  be  several  different  ways 
in  which  A  might  be  able  to  cause  B.  The  system  works  at  these  different 
levels  of  detail  to  pin  the  cansal  connection  down  to  the  degree  that  is 
required. 

It  is  important  to  note  that  these  systems  do  not  use  "causal  models”  as 
much  as  they  use  a  storehouse  of  compiled  cansal  aasociationa .  In  a  sense  all 
diagnostic  programs  use  "causal  models."  Much  of  the  diagnostic  knowledge  in 
MTCIH  or  MDX  jjj.  causal,  i.e.,  saying  "symptom  A  gives  so  much  evidence  for 
disease  B,"  is,  in  content,  the  same  as  ”B  causes  A  with  so  much  likelihood." 
The  difference  between  them  and  the  programs  above  is  what  is  done  with  the 
cansal  knowledge. 

In  onr  view  a  truly  deep  model  should  have  the  power  to  derive  the  causal 
connections  between  states.  The  work  of  Knipers  (1982),  deKleer  and  Brown 
(1981)  and  Chandrasekaran  and  Hoorthy  (forthcoming)  are  relevant  here. 

Knipers  proposes  methods  by  which  causal  behavior  may  be  derived  from  a 
knowledge  of  the  structure  of  some  system.  The  latter  two  references  seek  to 
model  functional  understanding  of  devices. 

The  scope  of  the  current  paper  does  not  allow  a  detailed  description  of 


how  the  function*],  representations  vork  and  how  they  are  related  to  diagnostic 
reasoning.  Here  we  content  ourselves  with  an  intuitive  account  o£  our 
approach. 

He  model  nTtdfyt^nding  of  £  device  as  the  creation  of  a  knowledge 
structure  which  is  hierarchically  organized  in  terms  of  functions  and 
subf unctions .  How  the  salient  behavior  (generally  stated  in  qualitative 
terms)  and  the  physical  structure  of  the  relevant  portions  of  the  device  play 
a  role  in  achieving  a  function  by  means  of  the  subfunctions  is  part  of  such  a 
description. 

We  believe  that  such  a  structure  can  be  used  to  generate  the  causal 
knowledge  needed  for  diagnostic  reasoning.  The  f unction/ subf unction 
relationship  can  be  used  to  generate  diagnostic  hypotheses.  If  function  A  is 
affected,  each  of  its  subfunctions  can  be  considered  as  a  possible  source  of 
failure.  Similarly  the  symptomatic  knowledge  that  is  needed  for  establishing 
or  rejecting  these  as  possibilities  can  be  derived  from  the  behavioral  and 
physical  structure  constraints  that  enable  subfunctions  to  be  achieved;  "if 
behavior  B  is  necessary  to  accomplish  subfunction  A',  look  for  evidence  or 
lack  of  B  in  the  behavior  of  the  device,"  e.g.,  would  be  a  useful  way  to 
generate  some  of  that  knowledge.  The  attempt  to  give  systems  a  degree  of 
understanding  based  on  functional  models  is  still  very  experimental,  and 
practical  expert  systems  based  on  this  approach  are  still  some  time  away.  But 
we  feel  that  this  sort  of  systems  is  the  next  step  in  the  evolution  of  expert 
systems  towards  a  greater  degree  of  understanding. 


9.  DISCUSS 101 


The  reader  may  heve  gathered  that  there  ie  no  simple  method  of 
determining  which  tasks  are  likely  to  be  successfully  handled  by  an  expert 
system.  9e  have  attempted  to  give  the  reader  some  analytical  tools  by  which 
such  a  decision  may  be  made  a  little  eaaier.  In  any  case,  the  following 
guidelines  arise  from  our  experience  in  designing  a  number  of  expert  systems, 

1.  When  the  total  amount  of  knowledge  is  relatively  small  (a  few 
hundred  rules),  the  exact  technique  used  is  not  very  important.  A 
wide  variety  of  techniques  will  all  give  similar  qualitative 
performance. 

2.  A  large  fraction  of  expert  systems  that  have  reached  some  degree  of 
exposure  (Prospector,  Mycin,  MDX,  CASHKT,  Internist)  deals  with  some 
form  of  the  classification  problem.  If  the  core  task  in  an 
application  domain  is  classificatory,  chances  are  very  good  that  an 
expert  system  approach  will  be  successful.  Problems  of  synthesis, 
such  as  design,  are  in  general  harder,  but  some  simpler  versions  of 
the  design  problem,  such  as  the  task  domain  of  11,  have  been 
successfully  attacked. 

3.  Another  type  of  expert  system  that  is  likely  to  be  of  practical 
applicability  is  one  that  helps  the  user  access  knowledge  in  a 
complex  knowledge  base.  This  type  of  expert  behavior  does  not 
require  the  full  problem  solving  capabilities  of  the  expert.  Our 
work  on  intelligent  data  bases  (Mittal  and  Chandrasekaran,  1980) 
offers  some  techniques  of  potential  relevance  here. 

A.  If  a  real-world  task  can  be  decomposed  into  a  number  of  generic 


Uiki  for  which  export  system  solutions  ore  available,  then  the 
prospect  of  a  successful  expert  system  increases  significantly. 

5.  Important  research  is  going  on  in  conon  sense  qualitative  reasoning 
involving  space  and  time;  these  advances  will  give  the  next 
generation  of  expert  systems  more  power  and  flexibility. 

6.  lessoning  of  experts  is  in  general  varied  and  broad-ranging.  We 
have  only  began  to  understand  some  forms  of  such  reasoning.  Honesty 
compels  ns  to  admit  that  it  is  not  a  simple  matter  to  capture  all 
forma  of  expertise  and  incorporate  thma  in  the  form  of  computer 
programs,  even  though,  in  the  enthusiasm  surrounding  this  promising 
field,  careful  distinctions  and  qualifications  often  do  not  get 
made.  On  the  positive  side  is  the  solid  body  of  accomplisfaswnt:  the 
field,  has  managed  to  capture  a  number  of  useful  forms  of  expertise. 

We  have  not  diseusaed  in  this  paper  a  number  of  issues  such  as  user 

interfaces,  explanation  facilities,  and  knowledge  acquisition  problems.  They 
are  obviously  of  great  practical  importance,  but  it  has  always  seemed  to  us 
that  the  issues  of  knowledge  organisation  and  problem  solving  will  continue  to 
occupy  the  center  stage  in  this  area,  since  these  problems  are  by  no  means 
solved. 
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